Systems and methods for sales execution environment

ABSTRACT

Systems, methods, and computer-readable storage mediums are provided for facilitating a task in a retail commerce environment. A request to facilitate performance of a commerce-related task is sent. In response to receiving the request, a task flow including an execution sequence for services associated with the commerce-related task is coordinated. The services are invoked in order according to the execution sequence. Rules and events associated with the services are triggered. Information is routed between rules, events, and services to facilitate completion of the commerce-related task. The services are maintained and customizations are administered to the services. A result of the performance of the commerce-related task is rendered.

RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.15/106,658, entitled “SYSTEMS AND METHODS FOR SALES EXECUTIONENVIRONMENT,” filed Jun. 20, 2016, which is a 35 U.S.C. § 371 NationalStage filing of International Application No. PCT/US2014/071559,entitled “SYSTEMS AND METHODS FOR SALES EXECUTION ENVIRONMENT,” filedDec. 19, 2014, which claims priority to U.S. Provisional PatentApplication Ser. No. 61/919,042, entitled “Systems and Methods for SalesExecution Environment,” filed on Dec. 20, 2013, U.S. Provisional PatentApplication Ser. No. 61/919,036, entitled “Systems and Methods for SalesExecution Environment,” filed on Dec. 20, 2013, U.S. Provisional PatentApplication Ser. No. 61/919,034, entitled “Systems and Methods for SalesExecution Environment,” filed on Dec. 20, 2013, and U.S. ProvisionalPatent Application Ser. No. 61/919,030, entitled “Systems and Methodsfor Sales Execution Environment,” filed on Dec. 20, 2013, which arehereby incorporated by reference in their entirety.

BACKGROUND

Point-of-Sale (POS) systems are used to complete sales transactions byaccepting payment from a customer. Traditional POS systems often onlyaddress transactions occurring in a physical store or an online store,rather than integrating all aspects of a sales process. Additionally,modifying traditional POS systems to incorporate changes in technologyand business is difficult. Most POS systems also do not provideinterface capabilities with third-parties.

SUMMARY

Exemplary embodiments of the present disclosure are directed tofacilitating a task in a retail commerce environment. In accordance withembodiments of the present disclosure, a system for facilitating a taskin a retail commerce environment is disclosed. The system includes ahardware-implemented presentation module that is configured to send arequest to facilitate performance of a commerce-related task and rendera result of the performance of the commerce-related task. The systemalso includes a hardware-implemented orchestration module that isconfigured to coordinate a task flow, in response to receiving therequest from a client device. The coordination of the task flow includesdetermining an execution sequence for the services associated with thecommerce-related task. The orchestration module is also configured toinvoke the services in order according to the execution sequence andtrigger rules and events associated with the service. The orchestrationmodule is also configured to route information based on the task flowbetween the rules, events, and services to facilitate completion of thecommerce-related task. The system also includes a hardware-implementedadministration module that is configured to maintain the services andadminister customizations to the services.

In accordance with embodiments of the present disclosure, thepresentation module may also be configured to facilitate interfacingwith a peripheral device that may be required for the performance of thecommerce-related task. The orchestration module may also be configuredto route the information using a messaging module that facilitatescommunication between various modules. The administration module mayalso be configured to perform real-time event pattern analysis tofacilitate performance of the commerce-related task. The system may alsoinclude a hardware-implemented market module that may be configured tomaintain services, rules, and events specific to a market, andadminister customizations to the services, the rules, and the eventsspecific to the market. The system may also include ahardware-implemented enterprise module that may be configured tointegrate operational systems of the retail commerce environment. Thesystem may also include a hardware-implemented security module that maybe configured to authenticate the client device and grant the clientdevice access to the system. The system may also include a messagingmodule that may be configured to translate communications from a sendermodule to a form understandable by a recipient module. The system mayalso include a hardware-implemented third-party module configured tointegrate third-party systems with the system, and the third-partysystems may include a third-party vendor, a compliance agency, or afiscal entity. The system may also include a market module that may beconfigured to receive information associated with a modification of theservice of the plurality of services, where the modification may includeassociating an event with the service, associating a rule with theservice, modifying the execution sequence, or adding an additionalservice to the execution sequence. The market module may furtherimplement the modification, and update the service and the executionsequence based on the modification, and invoke the plurality of servicesbased on the updated service and updated execution sequence.

In accordance with embodiments of the present disclosure, in a commerceenvironment, a computer-implemented method is provided for facilitatinga task in the commerce environment. A request to facilitate performanceof a commerce-related task is sent from a client device. In response toreceiving the request, a task flow is coordinated, which includes anexecution sequence for the services associated with the commerce-relatedtask. The services are invoked in order according to the executionsequence. Rules and events associated with the services are alsoinvoked. Information is routed based on the task flow between the rules,events, and services to facilitate completion of the commerce-relatedtask. The services are maintained and customizations are administered.The result of the performance of the commerce-related task is renderedfor the client device. The method also includes receiving informationassociated with a modification of a service. The modification mayinclude associating an event with the service, associating a rule withthe service, modifying the execution sequence, or adding an additionalservice to the execution sequence. The modification may be implementedand the service and execution sequence are updated. The services areinvoked based on the updated services and execution sequence. The methodmay also include a step of integrating with third-party systems such as,a third-party vendor, a compliance agency, or a fiscal entity. Themethod may also include interfacing with a peripheral device that may berequired for facilitating the performance of the commerce-related task.The method may also include performing real-time event pattern analysisto facilitate performance of the commerce-related task.

In accordance with embodiments of the present disclosure, anon-transitory computer-readable storage device configured to storeinstructions executable by a processing device is disclosed. Executionof the instructions in a retail commerce environment causes theprocessing device to implement a method for facilitating a task in theretail commerce environment. The processing device reads instructions tosend a request, from a client device, to facilitate performance of acommerce-related task, render a result of the performance of thecommerce-related task, and in response to receiving the request tofacilitate performance of the commerce-related task, coordinate a taskflow. The coordination of the task flow includes an execution sequencefor the services associated with the commerce-related task. Theprocessing device also reads instructions to invoke the services inorder according to the execution sequence, and also triggering rules andevents associated with a service. The instructions are also to routeinformation based on the task flow between the rules, the events, andthe services to facilitate completion of the commerce-related task,maintain the plurality of services, and also administer customizationsto the plurality of services. The processing device may also readinstructions to integrate third-party systems, where the third-partysystems may be a third-party vendor, a compliance agency, or a fiscalentity. The processing device may also read instructions to performreal-time event pattern analysis to facilitate performance of thecommerce-related task, and to interface with a peripheral device thatmay be required for the performance of the commerce-related task.

Exemplary embodiments of the present disclosure are directed toexecuting a multistep commerce-related task in a commerce environment.In accordance with embodiments of the present disclosure, acomputer-implemented method for executing a multistep commerce-relatedtask in a commerce environment is disclosed. The method includesreceiving a request in a computer-readable format for execution of acommerce-related task in a commerce environment, and programmaticallyretrieving a task flow from a non-transitory computer-readable medium inresponse to the request. The task flow identifies sub-tasks and definesa sequence with which to execute the sub-tasks to facilitate completionof the commerce-related task. The method also includes controlling anorder of execution of the sub-tasks according to the sequence defined bythe task flow. The sub-tasks are executed independently and discretelyof each other.

In accordance with embodiments of the present disclosure, the method mayalso include receiving a request to evaluate a rule associated with oneof the sub-tasks, and evaluating the rule based on criteriacorresponding to the rule. The method may further include receiving arequest to execute a sub-task of the sub-tasks, invoking a servicecorresponding to the sub-task, the service facilitating execution of thesub-task, receiving a result of the sub-task as a result of execution ofthe sub-task, and sending confirmation that the sub-task is executed.The request may be received from a client device, and the client devicemay be a device used by a customer, a sales associate, a departmentmanager, a floor manager, a sales manager, an inventory manager, asupplier, a distributor, or a third-party vendor. The commerce-relatedtask may include a task related to adding an item to a shopping cart,ordering an item, checking a price of an item, calculating a shippingcost for an item, paying for an item, or returning an item. The requestmay include context information associated with the commerce-relatedtask, the context information may be required to execute the sub-tasksof the task flow.

In accordance with embodiments of the present disclosure, a system forexecuting a multistep commerce-related task in a commerce environment isdisclosed. The system includes a processor implemented orchestrationmodule that is configured to receive a request in a computer-readableformat for execution of a commerce-related task in a commerceenvironment, and retrieve a task flow from a non-transitorycomputer-readable medium in response to the request. The task flowidentifies sub-tasks and defines a sequence with which to execute thesub-tasks to facilitate completion of the commerce-related task. Theprocessor implemented orchestration module if further configured tocontrol an order of execution of the sub-tasks according to the sequencedefined by the task flow. The sub-tasks are executed independently anddiscretely of each other.

In accordance with embodiments of the present disclosure, the system mayalso include a rule module configured to receive a request to evaluate arule associated with one of the sub-tasks, and evaluate the rule basedon criteria corresponding to the rule. The orchestration module mayfurther receive a request to execute a sub-task of the sub-tasks, invokea service corresponding to the sub-task to facilitate execution of thesub-task, receive a result of the sub-task as a result of execution ofthe sub-task, and send confirmation that the sub-task is executed. Thesystem may also include an extension module that may be configured toreceive a modification of the sub-task, and implement the modificationof the sub-task. The request may include context information associatedwith the commerce-related task, the context information may be requiredto execute the sub-tasks of the task flow. The commerce-related task mayinclude a task related to adding an item to a shopping cart, ordering anitem, checking a price of an item, calculating a shipping cost for anitem, paying for an item, or returning an item. The request may bereceived from a client device.

In accordance with embodiments of the present disclosure, anon-transitory computer-readable storage device configured to storeinstructions executable by a processing device is disclosed. Executionof the instructions in a commerce environment causes the processingdevice to implement a method of executing a multistep commerce-relatedtask in the commerce environment. The processing device readsinstructions to receive a request in a computer-readable format forexecution of a commerce-related task in a commerce environment, andretrieve a task flow in response to the request. The task flowidentifies sub-tasks and defines a sequence with which to execute thesub-tasks to facilitate completion of the commerce-related task. Theprocessing device further reads instructions to control an order ofexecution of the plurality of sub-tasks according to the sequencedefined by the task flow, the plurality of sub-tasks being executedindependently and discretely of each other.

In accordance with embodiments of the present disclosure, the processingdevice may also read instructions to receive a request to evaluate arule associated with one of the plurality of sub-tasks, and evaluatingthe rule based on criteria corresponding to the rule. The processingdevice may also read instructions to receive a request to execute asub-task of the plurality of sub-tasks, invoke a service correspondingto the sub-task, the service facilitating execution of the sub-task,receive a result of the sub-task as a result of execution of thesub-task, and send confirmation that the sub-task is executed. Thecommerce-related task may include a task related to adding an item to ashopping cart, ordering an item, checking a price of an item,calculating a shipping cost for an item, paying for an item, orreturning an item. The request may be received from a client device, andthe client device may be a device used by a customer, a sales associate,a department manager, a floor manager, a sales manager, an inventorymanager, a supplier, a distributor, or a third-party vendor.

Exemplary embodiments of the present disclosure are directed toreconfigurable rules in response to execution of a task in a commerceenvironment. In accordance with embodiments of the present disclosure, acomputer-implemented method of implementing reconfigurable rules inresponse to execution of a task in a commerce environment is disclosed.The method includes specifying a rule associated with a sub-task in amulti-step commerce-related task, the sub-task is implemented as aseparate sub-task data structure than other sub-tasks in the multi-stepcommerce-related task and the rule is implemented as a separate ruledata structure than the separate sub-task data structure. The methodalso includes executing the multi-step commerce-related task in acommerce environment, triggering the rule in response to execution ofthe sub-task, analyzing information generated in response to executionof the multi-step commerce related task to determine whether the rulehas been satisfied, and determining whether to continue executing themulti-step commerce-related task based on a determination of whether therule has been satisfied.

In accordance with embodiments of the present disclosure, the method mayalso include triggering the rule by invoking the rule as a separate taskwithin the sub-task. The method may also include modifying the rule bychanging the rule data structure, where modifying the rule may alter aprogrammatic behavior of the multi-step commerce-related task withoutmodifying the sub-task and the other sub-tasks of the multi-stepcommerce-related task. The rule may invoke one or more actions based ona bin number of a credit card being utilized to facilitate a commercetransaction. The rule may prompt a user via a graphical user interfaceto query a customer. The method may also include aborting the multi-stepcommerce-related task in response to determining that the rule has notbeen satisfied. The method may also include modifying the sub-task bychanging the sub-task data structure to alter a programmatic behavior ofthe multi-step commerce-related task without modifying the rule datastructure.

In accordance with embodiments of the present disclosure, a system forimplementing reconfigurable rules in response to execution of a task ina commerce environment is provided. The system includes a task moduleconfigured to specify a rule associated with a sub-task in a multi-stepcommerce-related task, the sub-task is implemented as a separatesub-task data structure than other sub-tasks in the multi-stepcommerce-related task and the rule is implemented as a separate ruledata structure than the separate sub-task data structure, and executethe multi-step commerce-related task in a commerce environment. Thesystem also includes a processor implemented rules engine configured totrigger the rule in response to execution of the sub-task, analyzeinformation generated in response to execution of the multi-stepcommerce related task to determine whether the rule has been satisfied,and determine whether to continue executing the multi-stepcommerce-related task based on a determination of whether the rule hasbeen satisfied. The triggering of the rule may include invoking the ruleas a separate task within the sub-task. The rules engine may furthermodify the rule by changing the rule data structure. Modifying the rulemay alter a programmatic behavior of the multi-step commerce-relatedtask without modifying the sub-task and the other sub-tasks of themulti-step commerce-related task. The rule may invoke one or moreactions based on a bin number of a credit card that is utilized tofacilitate a commerce transaction. The rules engine may further abortthe multi-step commerce-related task in response to determining that therule has not been satisfied. The task module may modify the sub-task bychanging the sub-task data structure to alter a programmatic behavior ofthe multi-step commerce-related task without modifying the rule datastructure.

In accordance with embodiments of the present disclosure, anon-transitory computer-readable storage device configured to storeinstructions executable by a processing device is disclosed. Executionof the instructions in a commerce environment causes the processingdevice to implement a method of implementing reconfigurable rules inresponse to execution of a task in the commerce environment. Theprocessing device reads instructions to specify a rule associated with asub-task in a multi-step commerce-related task, the sub-task isimplemented as a separate sub-task data structure than other sub-tasksin the multistep commerce-related task and the rule is implemented as aseparate rule data structure than the separate sub-task data structure.The processing device also read instructions to execute the multi-stepcommerce-related task in a commerce environment, trigger the rule inresponse to execution of the sub-task, analyze information generated inresponse to execution of the multi-step commerce related task todetermine whether the rule has been satisfied, and determine whether tocontinue executing the multi-step commerce-related task based on adetermination of whether the rule has been satisfied. The processingdevice may also read instructions to modify the sub-task by changing thesub-task data structure to alter a programmatic behavior of themulti-step commerce-related task without modifying the rule datastructure. The triggering of the rule may include invoking the rule as aseparate task within the sub-task. Modifying the rule may alter aprogrammatic behavior of the multi-step commerce-related task withoutmodifying the sub-task and the other sub-tasks of the multi-stepcommerce-related task.

Exemplary embodiments of the present disclosure are directed todetecting an event in response to execution of a task in a commerceenvironment. In accordance with embodiments of the present disclosure, acomputer-implemented method for detecting an event in response toexecution of a task in a commerce environment is disclosed. The methodincludes receiving information in response to an execution of a firstcomputer process corresponding to a first task in a commerceenvironment, analyzing the information to dynamically detect an eventbased on a contemporaneous formation of event criteria and to determinea priority of the event, triggering the event based on satisfaction ofthe event criteria, and determining whether to automatically initiateexecution of a second computer process corresponding to a second taskbased on the priority of the event.

In accordance with embodiments of the present disclosure, the method mayalso include distributing the event to one or more context groups basedon a type of event that is triggered or a type or commerce-related taskis executed. The method may also include invoking event orchestration,including performing a predefined sequence of services associated withthe event and may be required to perform a task in a commerceenvironment. The method may also implement a push model which includesdistributing the event to subscribers of the event, determining that theevent and consumer service are available, and in response to thedetermining, invoking the event orchestration. The push model may alsoinclude receiving a request to subscribe to the event, subscriptionallowing to receive a notification of the event occurring, and acceptingthe subscription. The method may also implement a pull model includingobserving the event in a topic, determining that the event is available,and in response to the determining, invoking the event orchestration.The pull model may further include in response to the determining,triggering another event instead of invoking the event orchestration.

In accordance with embodiments of the present disclosure, a system fordetecting an event in response to execution of a task in a commerceenvironment is disclosed. The system includes a processor implementedevent manager that is configured to receive information in response toan execution of a first computer process corresponding to a first taskin a commerce environment, analyze the information to dynamically detectan event based on a contemporaneous formation of event criteria and todetermine a priority of the event. The event manager also configured totrigger the event based on satisfaction of the event criteria, anddetermine whether to automatically initiate execution of a secondcomputer process corresponding to a second task based on the priority ofthe event. The event manager may be also configured to distribute theevent to one or more context groups based on a type of event that istriggered or a type of commerce-related task that is executed. The eventmanger may be further configured to invoke event orchestration,including performing a predefined sequence of a plurality of servicesassociated with the event and required to perform a task in a commerceenvironment. The system may also include a push module configured todistribute the event to subscribers of the event, determine that theevent and consumer service are available, and in response to thedetermining, invoke the event orchestration. The push module may also beconfigured to receive a request to subscribe to the event, where thesubscription allows to receive a notification of the event occurring,and accept the subscription. The system may also include a pull moduleconfigured to observe the event in the topic, determine that the eventis available, and in response to the determining, invoke the eventorchestration. The pull module may also in response to the determining,trigger another event instead of invoking the event orchestration.

In accordance with embodiments of the present disclosure, anon-transitory computer-readable storage device configured to storeinstructions executable by a processing device is disclosed. Executionof the instructions in a commerce environment causes the processingdevice to implement a method for detecting an event in response toexecution of a task in the commerce environment. The processing devicereads instructions to receive information in response to an execution ofa first computer process corresponding to a first task in a commerceenvironment, analyze the information to dynamically detect an eventbased on a contemporaneous formation of event criteria and to determinea priority of the event. The instructions further to trigger the eventbased on satisfaction of the event criteria, and determine whether toautomatically initiate execution of a second computer processcorresponding to a second task based on the priority of the event. Theprocessing device may also read instructions to distribute the event toone or more context groups based on a type of event that is triggered ora type of commerce-related task that is executed.

In accordance with embodiments of the present disclosure, the processingdevice may also read instructions to invoke event orchestration, andperform a predefined sequence of services associated with the event andrequired to perform a task in a commerce environment. The processingdevice may also read instructions to distribute the event to subscribersof the event, determine that the event and consumer service areavailable, in response to the determining, invoke the eventorchestration, receive a request to subscribe to the event, where thesubscription allows to receive a notification of the event occurring,and accept the subscription. The processing device may also readinstructions to observe the event in the topic, determine that the eventis available, and in response to the determining, invoke the eventorchestration. The processing device may also read instructions totrigger another event instead of invoking the event orchestration.

Any combination or permutation of embodiments is envisioned. Otherobjects and features will become apparent from the following detaileddescription considered in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure is illustrated by way of example, and notlimitation, in the figures of the accompanying drawings, in which likereference numerals indicate similar elements unless otherwise indicated.In the drawings,

FIG. 1 is a diagram of an exemplary system illustrating actors anddevices capable of communication with a sales execution environment,according to an example embodiment;

FIG. 2 is a diagram of an exemplary system illustrating theMarket-sensitive interfaces and Enterprise interfaces integrated with asales execution environment, according to an example embodiment;

FIG. 3 is a diagram of an exemplary system illustrating the variousstore systems that co-exist with a sales execution environment,according to an example embodiment;

FIG. 4 is a diagram of an exemplary system illustrating the variousarchitectural layers with a sales execution environment, according toexample embodiment;

FIG. 5 is a diagram of an exemplary system illustrating variouscomponents of the architectural layers of a sales execution environment,according to an example embodiment;

FIG. 6 is a diagram of an exemplary system illustrating variouscandidate services and their stereotypes of an orchestration layer in asales execution environment, according to an example embodiment;

FIG. 7 is a diagram of an exemplary system illustrating interactionsbetween various candidate services of the architectural layers of asales execution environment, according to an example embodiment;

FIG. 8 is a diagram of an exemplary system illustrating an examplecomponent model and interactions and dependencies between each layer ofa sales execution environment, according to an example embodiment;

FIG. 9 illustrates components configured to perform a sales processwithin a sales execution environment, according to an exampleembodiment;

FIG. 10 is a chart of an exemplary process illustrating the “Add Itemsto the Basket” component of the high-level sales process in a salesexecution environment, according to an example embodiment;

FIG. 11 is a diagram of an exemplary system illustrating a persistencecomponent model of a sales execution environment, according to anexample embodiment;

FIG. 12 is a chart illustrating the various deployment profiles withinfour deployment zones in a sales execution environment, according to anexample embodiment;

FIG. 13 is a diagram of an exemplary process illustrating example stepsof a push model in a sales execution environment, according to anexample embodiment;

FIG. 14 is a diagram of an exemplary process illustrating example stepsof a pull model in a sales execution environment, according to anexample embodiment;

FIG. 15 is a chart of an exemplary method for facilitating execution ofa task using a sales execution environment, according to an exampleembodiment;

FIG. 16 is a block diagram of an exemplary computing device forimplementing embodiments of the present disclosure, according to anexample embodiment;

FIG. 17 is a block diagram of an exemplary client-server environment forimplementing embodiments of a sales execution environment as describedherein.

DESCRIPTION OF EXEMPLARY EMBODIMENTS

Systems, methods and computer-readable media are provided for a SalesExecution Environment in a commerce environment. The Sales ExecutionEnvironment (SEE), among other things, empowers the customer to shopanywhere at any time, and inspires the customer with product and serviceofferings. The SEE supports customer devices and channels of choices,allowing the customer to shop as they want.

In exemplary embodiments, the SEE provides an architecture, governance,roles and relationships that deliver systems and processes to supportin-store, near-store, and remote customer interactions. The SEE providescustomer-facing systems which support seamless cross-channel customerbrowsing and shopping interactions within store or near-storeenvironments. As such, the SEE includes architectural features andfunctions that support the point-of-sale experience as well asinterfaces and integration to enterprise and vendor systems, combinedwith governance and operating models to manage and deliver thefunctionalities described herein. The SEE addresses market and customerrequirements at a global level while emphasizing market autonomy.Individual markets are able to innovate and deliver market-specificcapabilities at their own market-speed. These capabilities may beincorporated into a global platform whenever there is cross-marketpotential.

The SEE delivers business capabilities that enable the next generationof sales execution. The benefits of the SEE include flexibility tochange at the speed of local business and provide a competitive edge,and enable markets to design and deliver user interfaces and processesthat are up-to-date with current and future sale-models. The SEE alsodelivers an efficient store platform to innovate faster in localmarkets, and enables the store of the future and supports new formatsand initiatives such as the Merchant Customer Exchange (MCX) andplatform for mobile payments.

In some embodiments, the SEE can be implemented on a software platformthat is referred to as the Sales Execution Platform (SEP) for discussionpurposes. The SEP architecture guides designers with a known, butlimited set of choices, and provides markets the ability to innovatelocally. The SEP advantageously utilizes extensibility to provide aflexible and dynamic environment for implementing processes, tasks,operations, and the like associated with a commerce environment. The SEPis designed to accommodate flexible business models, such as,omni-channel, consumer-centric, market-specific payment trends(contact-less, mobile devices, smart cards, traditional). The SEP canalso accommodate market differences in various areas (geographicaltrends, store and brand trends, demographics), change in technology, avariety of devices for a variety of actors, and in a number of flexibledeployment scenarios. Service-oriented integration of the SEP balancesloose-coupled components with performance. The SEP also provides animproved customer experience, and leverages common services and data tosimplify maintenance and deployment. For example, one component isprovided to manage the SEP, while another component is provided tochange the SEP.

For example, the SEP utilizes modularity of components to providefunctionalities of the SEE. For example, instead of defining a processto complete a task as a single large component exemplary embodiments ofthe SEP are programmed or configured to break the process up intovarious small or sub components. Because of the modularity of thecomponents, components can be reused to fulfill different tasks, and itis easier to deploy individual components after modifications. Forexample, a process for adding items to an electronic shopping basketimplemented as various software components, such as, calculate discount,calculate taxes, evaluate restricted item rule, and the like. Anorchestration component, discussed in detail below, is responsible forrealizing when these components need to be executed, and which entityneeds to be called to execute them. After these various components areexecuted in a specified sequence, the task of adding items to theshopping basket is completed. Since, calculate discount and calculatetaxes are separate components that do not necessarily depend on theoverall task of adding items to the shopping basket, these componentscan be used in other tasks with or without being modified. For example,the calculate discount and calculate taxes components can be used incompleting a task of accepting payment because the discounts and taxeshave to be recalculated in case a price of an item in the shoppingbasket changed by the time the customer is ready to pay. Instead ofdeveloping new components for discount and taxes, the same componentsfrom the add items to the shopping basket process can be used for theaccept payment process. Furthermore, changes to the calculate discountand calculate taxes are applied to the component itself, and theprocesses for the different tasks or components do not need updating.The processes automatically use the updated components. In this manner,the modularity of the components of the SEE simplifies modifications,maintenance and deployment of processes due to market changes andinnovation.

The SEE and SEP facilitate execution of a sales transaction as describedbelow. A sales transaction, as used in the present disclosure, can referto any commerce-related task that needs to be performed in a commerceenvironment. The commerce-related task can be a multi-step task thatincludes one or more sub-tasks. The multi-step commerce-related task andthe sub-tasks may also be referred to as candidate services or services,within a service-orientated architecture. The various aspects of the SEEand SEP are described below in more detail. Some of these aspects arediscussed as being implemented with store systems and processes.However, it should be understood that the systems and methods disclosedherein can be implemented as part of any business entity to enhancetheir commerce-related processes.

Actors and Devices

Various actors and devices interact with the SEE. An actor is a userinteracting with the SEE. An actor may refer to a class of user rolesrather individual users or specific user roles themselves. For example,actors may correspond to a Customer-Facing Associate role. TheCustomer-Facing Associate role is a class of user roles that includes,for example, actual store roles, such as Front End Cashier, CustomerService Desk, and the like. Actors can use devices to interact with theSEE. A device may be any point-of-contact with the SEE and can include,for example, multipurpose workstations, consumer devices (e.g., mobilephones, tablets, etc.), static touchpoints, untethered associatetouchpoints, and the like. The devices interacting with the SEE may havevarious characteristics. Some of these characteristics can include, butare not limited to ownership (in-house owned versus customer-owned),portability (affixed to a store versus handheld device), andfunctionality (the number of functions it can perform).

Devices support predefined interactions between actors and the SEE.These interactions may describe functional characteristics of componentsbuilt into the SEP, and may also imply non-functional requirements (forexample, system availability, service level agreements, and the like)that the components may support. For example, a Customer-FacingAssociate (actor) using a Tablet (device) outside the store may requirethat SEP provide a store-forward capability (e.g., component) to allowthe Associate to transact sales without concern of network connectivityissues. As another example, SEP may allow a Customer (actor) at a storeKiosk (device, for example, a multipurpose station or an in-storestation) to combine their online order with in-store items into a singleshopping basket while preventing them from viewing another Customer'sorders or access store sales data. In this manner, an actor/devicecombination may be used to determine valid combinations, defineinteractions with the SEP, implement key use cases, and implementnon-functional requirements of the SEP.

One example of the actors may be an Associate Manager role. TheAssociate Manager role includes associates that have managerialresponsibilities such as associate scheduling, overriding and approvingtransactions, and monitoring store activities. Such associates may be,for example, a pharmacist (a salaried associate that manages thepharmacy and is accountable for prescriptions), a customer servicemanager or customer operations supervisor (a supervisor who monitors thefront end cashiers, manages cash flow, overrides and the register, andscheduling enforcement), a front end manager (a manager that coordinatescustomer service managers, and maintains a consistent checkoutexperience), an assistant manager (an assistant manager that isaccountable for the store), a store manager (a manager that isaccountable for the store), and the like.

Another example of the actors may be a Back Office Associate role. TheBack Office Associate role includes associates that may performfunctions, such as stocking the shelves or supporting store operationswith tasks like balancing daily store funds, coupons, accounts, and thelike. Yet another example of the actors may be a Customer role. TheCustomer role includes consumers that shop in a store for merchandiseand services, and have opted to share their personal information so thatthey are recognized by the SEP. Such people may use store services likePharmacy, Automotive Care (for example, Tire and Lube Express), Jewelry,Bill Paying, Money Desk, and the like. By providing personalinformation, they can transact across multiple channels and receivepersonalized offers and coupons. As mentioned above, one of the actorsmay include a Customer-Facing Associate role. The Customer-FacingAssociate role includes associates in customer-facing roles such as theFront End Cashier, Customer Service Desk, Money Service Desk Cashier,Vision Center Associate, Automotive Care Associate, Jewelry Associate,Layaway Associate, Sporting Goods Associate, Pharmacy TechnicianAssociate, Customer Service Associate, the Line Rusher Associate and thelike.

One example of actors may be a Member role, which includes customersthat purchased a membership account with one or more stores operated bya business entity utilizing the SEP. This account may be valid for apre-determined period of time, for example, one year. MultipleCustomers, for example husband and wife, can belong to a single account.Like Customers, Members can transact in multiple channels and receivepersonalized coupons and offers. In addition, Members receive benefitsfrom the store(s), such as rewards and special discounts on servicessuch as travel and insurance. Another example of actors may be a Shopperrole, which includes people that shop in a store for merchandise andservices. Unlike Customer, this Actor may be anonymous to the store.Shoppers may use mobile devices at the store, but can only transact in asingle channel (the store).

As discussed above, devices may include, for example, a Consumer Device,a Multipurpose Workstation, a Static Touchpoint, and an UntetheredAssociate Touchpoint. A Consumer device may be devices owned byCustomers, Shoppers or Members that are capable of interacting with theSEE. Such devices include, but are not limited to, personal computer,laptop, mobile device, smartphone, cellular phone, tablet, personaldigital assistant (PDA), smartwatch, portable global positioning system(GPS), vehicle navigation system, cash register, bar-code scanner,printer, and the like. A Multipurpose Station may be personal computers(PCs) that are used for various purposes at the store in areas such asPharmacy, Automotive Care and the Customer Service Manager (CSM)Workstation which is used by a Customer Service Manager to, for example,manage cashiers, breaks, lunches, change orders, price lookups, and thelike. A Multipurpose Station may also include devices such as laptop,mobile device, smartphone, cellular phone, tablet, personal digitalassistant (PDA), cash register, and the like. A Static Touchpoint may bedevices that are physically anchored to the store, such as, Scales,Scanners, Printers, Coin/Bill Accepter-Dispensers, Debit Readers,Registers, Self-Checkout Registers, Controllers, Kiosks, and the like.An Untethered Associate Touchpoint may be store-owned and operateddevices that allow the associates to move around the store as they helpCustomers, Shoppers and Members. Such devices may include, but are notlimited to, laptop, mobile device, smartphone, cellular phone, tablet,personal digital assistant (PDA), smartwatch, scanners, and the like.

FIG. 1 is a diagram of an exemplary system 100 illustrating actors 110,115, 120, 125, 130, 135, 140 and devices 150, 155, 160, 165 capable ofcommunication with the SEP 101, according to an example embodiment.System 100 includes actors internal to or employed by the store(s), suchas, Associate Manager 110, Back Office Associate 115, andCustomer-Facing Associate 120. System 100 also includes actors externalto store(s), such as, Shopper 130, Member 135, and Customer 140.Devices, such as, Multipurpose Workstation 150, Untethered AssociateTouchpoints 155, Static Touchpoint 160, and Consumer Device 165, arealso included in system 100. These actors and devices are capable ofinteracting with the Sales Execution Platform 101 that is implementedutilizing embodiments of the Sales Execution Environment (SEE) asdescribed herein.

External Interfaces

To support a retail business model, the SEE is integrated with variousMarket-sensitive interfaces and Enterprise interfaces (e.g., customerand vendor facing interfaces), which are discussed in more detail below.The SEE empowers innovation in at least three following ways: (1)configuration, including the ability to customize for market-specificbehavior without code changes, (2) extension, including the ability toenhance SEP with market-supplied components within the confines of anSEP interface, and (3) augmentation, including the ability to deploymarket-owned interfaces and components that amplify SEP functionality ina way that is unique to the market.

FIG. 2 is a diagram of an exemplary system 200 illustrating theMarket-sensitive interfaces and Enterprise interfaces integrated withthe SEE and utilized by the SEP 201, according to an example embodiment.Market interfaces refer to interfaces that may be configured forspecific business units based on, for example, a particular country orenvironment. For example, Market interfaces may be available for clubmember stores or stores in Brazil or India. Enterprise interfaces referto interfaces that may be configured for some, all, or none of thestores as well as enterprise offices associated with the stores. Thevarious interfaces included in system 200 are described below. Theinformation communicated between the interfaces and the SEE 201 are alsodescribed below. The Market-sensitive interfaces may include thefollowing interfaces 211-228 described below.

Third-Party Services Interface 211 are applications and services such asFuel, Photo, Jewelry, Hair Salon, Restaurant, Automotive Care, and thelike, which interact with the SEP 201 to collect payment and printnecessary documents such as Receipts and Warranty Information. Healthand Wellness Interface 212 includes systems supporting pharmacy andoptical goods and services. The Health and Wellness Interface 212handles special security considerations that may be required to assurecompliance with Health Insurance Portability and Accountability Act(HIPAA) and Personally Identifiable Information (PII) polices. PaymentProcessing Interface 213 handles market-specific technology or productused to collect payments from Shoppers or Customers. The PaymentProcessing Interface 213 may support over 40 tender types, includingcredit card, gift card, debit cards, and the like.

Customer Order Management Interface 214 manages customer-facing orderswhich enables store(s) to sell any inventory in its supply chain, notjust what is currently on the shelves. In an omni-channel environment,the Customer Order Management Interface 214 enables store(s) to sellanywhere, order anywhere, fulfill from anywhere, and dispense it to thecustomer at the time, place and manner of their choosing. The CustomerOrder Management Interface 214 enhances the customer's experience andsend the brand message that the store is here to help them save money sothey can live better. Workforce Management Interface 215 manages thelocal rules regarding Associates' time and attendance. These rules areoften for hourly employees (e.g. payroll) and are different thanscheduling rules. For example, a rule may not allow a Cashier to log inwhile they are clocked out. There is a repository of the store employeesthat have been granted roles to access the SEP.

Document Generation Interface 216 is responsible for generatingdocuments such as receipts, contracts, warranties and other suchcommunications relevant to the items being purchased. The DocumentGeneration Interface 216 handles transactions that require certaininformation be printed on a receipt or use a specific printer for itsgeneration. Government Agency Interface 217 handles interactions betweengovernment agencies and the store(s) for purposes of compliance and/orfiscal requirements. For example, the Chilean Government may requirethat customers are identified prior to completing transactions. Otherexamples include anti-money laundering detection and purchases ofhazardous items. Tax Management Interface 218 is an interface to systemsthat embody the rules imposed by fiscal or government agencies tocollect sales taxes per applicable tax jurisdiction regulations.

Customer Experience Management Interface 219 uses knowledge of thecustomer to present opportunities to increase the level of serviceprovided or profitable customer interactions which they are interestedin, including personalized content and offers to be displayed at POSdevices. Marketing Strategy and Planning Interface 220 determinespromotional messages and influence shopper purchase through a variety ofinteraction points. Shopping Experience Management Interface 221addresses a demographic or some segment of shoppers, without the abilityto specifically know them as a person. For example, if a customer buys aspecific food item, recipes associated with the food item may beoffered. It may also be responsible for providing content to bedisplayed at POS devices.

Coupon Services Interface 222 provides the ability to handle not onlyphysical coupons, but virtual ones as well, and also be able to show thecustomer specific coupons which could help them lower the cost of theirpurchase even though they may not have known about their existence.Pricing Strategy Interface 223 consists of system(s) that encapsulatethe rules regarding promotions and discounts. The Pricing StrategyInterface 223 includes link-saves and item discounts (for instance whena certain group of items are purchased together). Payment RulesInterface 224 handles the variety of rules associated with payment. Forexample these rules may include, items that cannot be bought under theWomen In Crisis (WIC) program, items that cannot be bought under theState Nutritional Assistance Program (SNAP) program, PaymentRestrictions (cannot buy alcohol with certain card form of payment), andthe like.

Sales Rules Interface 225 is a suite of applications managed in acentral facility by, for example, a compliance team. The Sales RulesInterface 225 may include, for example, a rule that prevents a storefrom selling a recalled item. Other rules include tax exemptions, taxflags (person needs to have certificate for exempt taxes), restrictions(Over 21 buying alcohol), Warranty (battery warranty), and bundlingitems. Financial Services Interface 226 handles the sale of serviceswhich involve financial transactions, such as, Bill Pay, Money-Gram,Check-Free, and the like, with the exclusions of banking services. Theseservices include collecting information needed for the successfulcompletion of the service.

Sales Management Interface 227 handles specific interactions required inrunning a profitable store. The Sales Management Interface 227 includesback office applications such as the decision support store Sales byhour, exception reports, store within a store, club within a club, loadcalendar data for “Store Within A Store” (SWAS) recap, Top 20 on handchanges, out-of-stock. SWAS refers to departments within a store thatmay be run independently from the store, therefore, run as a storeitself. In some embodiments, data can be purged on a periodic oraperiodic bases. For example, this data can be purged on a “SpecificMeasurable Actionable Relevant Time-bound” (S.M.A.R.T) basis. It mayfurther include Register Configuration, Cashier Restrictions, CashierRoles, Cashier Schedule, Application that balances all payments, sum upall coupons, checks, and reconciliation is done within the store,Department sales, Register sales, Tax, Bank Card, and the like. ShippingOperations Interface 228 handles the ability to deliver store purchasesto the customer's home or allowing stores to complete online orders bytaking advantage of lower local shipping rates or local inventory.

Inventory Management/Perpetual Inventory Interface (not shown) providesfor fiscal accounting of inventory as well as the ability to trackcurrent inventory counts. While ‘brick-n-mortar’ stores may focus onusing inventory counts for merely replenishing inventory, theomni-channel environment may need access to accurate counts to assurethe completion of a customer's online order in addition to replenishinginventory. Store Management Tools Interface (not shown) consists ofmanagement tools that allow supervisors and managers to see restrictedinformation, make configuration changes for operational purposes andreview financial reports.

The Enterprise interfaces may include interfaces 230-237 describedbelow.

Asset Management Interface 230 has the ability to track assetsfinancially and assure proper maintenance of assets. The AssetManagement Interface 230 also supports a depreciation cycle of theassets as this enables possibilities to end-of-life some equipment.Price Execution Interface 231 is a system that provides the officialprices for the items being sold at the store. Merchandise ReturnsInterface 232 includes systems that deal with returning merchandise to asupplier after a Customer Return.

Enterprise Insights Interface 233 generates Sales Reports, and isresponsible for reporting on sales data for the purposes of BusinessIntelligence. There are at least two roles: to manage the tables in thestore where everyone gets their data, and to make sure stores have cleandata. At the central facility they go through and have an hourly anddaily extract, in which they analyze and aggregate the data to provide aplace for stores to get their data. Treasury Handling Interface 234reconciles payments and balance accounts before they are written intothe general ledger. The Treasury Handling Interface 234 also providesthe bin ranges that are used to determine how to settle transactions.Bin ranges are an input to payment rules.

Fulfillment Management Interface 235 leverages the entire supply chaininventory to complete a customer's purchase. The transportation networkand local stores can be leveraged to expand the assortment offered tocustomers. Examples include current interactions with store departments,such as Global E-Commerce (GEC), Jewelry, Automotive Care, and the like.This ability can be important when there is a basket full of item andservices, and the only action left is to get payment for them. CustomerAccount Maintenance Interface 236 is a data repository of customerinformation built from shoppers that opted-in to the SEP. While the SEPmay not own customer data, it does consume it in the form of CustomerProfiles. For the purposes of the SEP, a club member (e.g., a customerthat pays a fee for the ability to shop in a specified store) is treatedas a special type of Customer. The Customer Account MaintenanceInterface 236 allows customers to ‘opt-in’ to sharing specificinformation about themselves for expanded service and promotionalopportunities.

Product and Service Catalog Management Interface 237 providesinformation about Offerings, Products and Items, including both centralfacility as well as Store Items. There are at least two types of itemsthat reside on separate systems. Central facility items are managedcentrally and as a consequence, there are purchase order andreplenishment processes in place for these. In contrast, Store Items areunique to and sold by a store, for example, a Store Item can be applesgrown by a local farm. Store Items may not benefit from the sameenterprise replenishment and ordering processes as central facilityitems. In an example embodiment, these two types may be serviced by asingle interface, rather than making multiple services that aresensitive to the nuances of the differences between the two. The Productand Service Catalog Management Interface 237 may also support theability to leverage rich product information in stores, similar to theexperience created online. Any information that can help customers learnmore about their purchases helps influence the shopping experience.

The following information described may be communicated from theinterfaces to the SEP 201. Approval Information such as successfulpayment transaction for a specific authorization. Associate SecurityProfile Information includes associates personal information,preferences and application roles. Bankcard Information is a file usedby a cash office to balance sales transactions against a till drawer.Bin Range Information includes credit card number ranges used toidentify the issuing credit agency. Bundle Information is a collectionof items, when present, allow for a discounted price. Cashier RolesInformation includes information related to roles such as an underage,cashier or supervisor. Cashier Schedule Information includes weeklyschedule an associate is expected to work. Content Information isinformation shared through an application which is published as needed.

Credit Application Information is information that may be collected andsubmitted for consideration of extending credit. Customer CredentialsInformation is a token used to identify store customers. An accountassociated with Google, Facebook, or other services may be used toidentify the specific customer profile. Customer Profile Information isinformation regarding customer preferences, order history, name,bill-to, ship-to, payments, default ship-to, save for later list,shopping list, coupon list, and the like. Deferred Payment Informationis the ability of the store to complete an online purchase in the storewith the payment collected and authorized online. Department Informationincludes information related to a unique collection of merchandise thatmay be sold. Discount Information may be an associate discount or adiscount applied to the overall order. For example, the customer mayhave a special card which qualifies them for certain amount of discounton the purchase of specific merchandise.

Instant Credit Information is the information to process a creditapplication instantly and extend credit to the merchandise beingpurchased. Item Information is information that helps identify themerchandise. Item Price Information is the price information for aspecific item at a location. The Item Price Information represents thecurrent charge for an item, regardless of any appropriate discounts orcoupons. Location Information is a physical, geographic location where acustomer is at a particular point in time. Offering Information is theservice or good that can be sold to the customer. Order Information isinformation for a transaction which represents the customer purchase ofmerchandise. The Order Information can represent a customer order frominventory in the supply chain, or merchandise being purchase at thestore as a sales transaction.

Packaging Weight Information is the mass of the container the item ispackaged in. The Packaging Weight Information is to allow to only chargeper pound for the item and not charge for the weight of the packaging.Payment Acknowledged Information is the token used to reconcile paymentsbetween the POS, Cash Office and electronic payment (Epay) systemsagainst what is settled with the Payment Issuers. Payment CredentialsInformation represents the physical or virtual credential accepted bypayment systems to allow a credit charge. Payment CredentialsInformation reserves the right to collect on a debt, and not on theactual transfer of tender. Product Information is the informationrelated to the item on the shelf. While an item is tied to a specificsupplier, the Product Information is meant to represent the informationpresented to the customer to influence the purchasing decision.Promotion Line Information is information related to the merchandisebeing advertised to bring brand awareness or offer a reduced price toincrease our rate of sale.

Recall Information are items which cannot be sold any longer due toconcerns over the health and safety of customers. The Recall Informationis often tied to a specific lot the item was manufactured in or to aspecific supplier. Register Information is information related device orsystem used to complete transactions for goods or services. RegisterConfiguration Information is the unique workflow the register isconfigured to follow given the merchandise being sold. Examples ofunique workflows include workflows for purchasing Gun, Tobacco, CellPhones, and the like. Restriction Information is a condition that mustbe enforced to ensure compliance with policies and regulations. Forexample, a restriction can be that a town does not allow alcohol to besold on Sundays. Returned Merchandise Information is merchandise that acustomer brings into the store to ask for a refund of payment. TheReturned Merchandise Information can also be utilized for creating aclaim with the supplier for credit. In some embodiments, merchandise isjust destroyed as it is not worth the cost to return.

SNAP Information refers to information for the Supplemental NutritionAwareness Program (SNAP) that offers assistance for low income citizensin their food purchases. The SNAP Information includes, for example,restrictions as to what a customer participating in SNAP can purchase.For example, a customer participating in SNAP cannot purchase tobacco.Tasks Information is information relating to specific activities thatare assigned to associates to complete the work needed for the operationof the store. Tax Information is the tax that is to be collected for thesale based on specific government jurisdictional regulations. The taxmay depend on multiple jurisdictions (city, county, state, federal,export, VAT, and the like) and multiple taxes on merchandise (sales tax,soda tax, and the like). Tax Due Information is the amount calculated asper government or fiscal organization rules based on the purchase aspecific item. Tax Exemption Flags Information is the ability of an itemto be excluded from a tax calculation, provided the customer has a taxexempt certificate on file.

Templates Information is basic layout patterns for specific documentsthat need to be generated. Top Billers Information are items which helpdrive consumers into the stores. Warranty Information is insurance on anitem which allows for repair or replacement services for a period oftime. Women, Infants and Children (WIC) Information is informationrelated to a government program that allows lower income parents to payfor the necessary items to help raise healthy kids.

The following information described may be communicated to theinterfaces from the SEP 201. Clock-in/out Information is the ability ofassociates to track their time on the clock. The Clock-in/outInformation may only be needed for hourly associates to be paid based onhours worked. Document Type Information is specific type of documentneeding to be generated such as a Receipt or a Service Contract. SalesData Information is a report on current value of sales transactions.Sales Transaction Information is an order created from a customerpurchase of a shopping basket of items, with a focus on buying in thestore or the club. Shopping Basket Information is a collection of itemsthe customer desires to purchase. The Shopping Basket Information is theinformation available to systems to transact sales, for example, given aShopping Basket, the SEP 201 collects payment and complete the sale.

Store Systems

FIG. 3 is a diagram of an exemplary system 300 illustrating the variousstore systems that co-exist with the SEE within the SEP 301, accordingto an example embodiment. The diagram also includes the types ofinformation that is shared with each system. The following store systemsdescribed are examples of systems that may co-exist with SEE. TreasurySystem 310 is a system that handles the end of day settlement processfor all types of electronic tenders, such as, electronic payments,check, debit cards, credit cards, and the like. The Treasury System 310may also route the payment information to corresponding banks. The SMARTSystem 320 is a system in the back office. Each store may have one SMARTSystem 320 that acts as a single point of distribution of data in or outof the store including register sales, department sales, bankcardinformation, T-LOGs, and the like.

A Host POS System 330 is a system that handles debit authorization,check authorization, item refund, NOF item lookup and associatediscounts. EPAY System 340 is a system that deals with electronicpayment requests from the registers. The EPAY System 340 is anintermediary between the POS and the payment authorizers. General SalesApplication System 350 is a system that controls a variety ofpoint-of-sale terminals. The General Sales Application System 350 Alsosupports store opening and closing processes and reports. Market BasketSystem 360 is a system that processes the raw T-LOGs from the stores andfeeds other backend systems with information extracted from them. MasterController (CC) System 370 is a system that controls the terminals andmanages the communications with upstream systems. The Master ControllerSystem 370 is an interface to send transaction related data and toreceive files needed for transaction execution. The Master ControllerSystem 370 hosts various applications that monitor and enable terminalsto complete transactions. Alternate Master (DD) System 380 is a systemthat is the backup to the Master Controller System 370.

Architecture

The fundamental building blocks of the SEP may be referred to asarchitectural layers. An architectural layer can further be described bythe responsibilities allocated to it. Inside each layer is a set ofcandidate services that constitute the basic elements of that layer.These candidate services provide the functionality that delivers theresponsibility assigned to that layer, depicting the “types of things”that can reside in that specific layer. A candidate service is aself-contained unit of functionality. Multiple candidate services can becombined to provide a larger functionality, for example, execution of asales-related task that has multiple steps.

FIG. 4 is a diagram of an exemplary system 400 illustrating the variousarchitectural layers with the SEP, according to an example embodiment.The architectural layers include, but are not limited to, a device layer410, a presentation layer 420, a federated messaging layer 430,orchestration layer 440, security and monitoring layer 450, a foundationlayer 460, a market layer 470, an enterprise layer 480, and athird-party layer 490. Although, FIG. 4 shows system 400 including onlythese layers, it is understood that there may be more or fewer layersincluded in system 400, and their names and functions may vary.

The device layer 410 is responsible for enabling interactions betweenActors and the SEP to facilitate performance or one or more tasks,services, processes, operations, or functions by the SEP for salesexecution, as described herein. The presentation layer 420 isresponsible for device-specific rendering and optimization componentsthat enable task delivery. The federated messaging layer 430 isresponsible for decoupling service providers and service consumers. Thisis where infrastructure-enabling components may provide features likebrokering, routing and transformation. The orchestration layer 440 isresponsible for service invocation, sequencing rules, and eventmanagement. The presentation layer 420 candidate services and othercandidate services invoke candidate services of the orchestration layerto execute their multi-step tasks. In contrast to hardcoding serviceinteractions, this layer provides engines that help decouple howservices interact with each other. The security and monitoring layer 450is responsible for maintaining the integrity of the data andcommunications of SEP services.

The foundation layer 460 is responsible for cross-market services andservice interfaces, SEP administration capabilities (to configureorchestrations, rules and events) and notification techniques. Themarket layer 470 is responsible for the market-specific components andservices. In this layer Markets can extend or augment SEP for theirbenefit. The enterprise layer 480 is responsible for leveraging existingenterprise capabilities and services and integrating with operationalsystems of the enterprise. The third-party layer 490 is responsible forencapsulating third parties from SEP components including vendors,compliance agencies and fiscal entities.

The SEE system is designed so that there is just-enough guidance tooperate the system without restricting future possibilities. FIG. 5 is adiagram of an exemplary system 500 illustrating various components ofthe architectural layers of the SEP, according to an example embodiment.The vertical dotted lines 502 represent configuration. Configuration isthe ability to customize the SEP or its layers without changing therunning components. As an example in the foundation layer 510, the SEPOrchestration component 511 is shown as configuring the OrchestrationEngine component 541 of the orchestration layer 540. Since thefoundation layer 510 is responsible for cross-market concerns, thisrelationship may be interpreted as configuring the cross-marketorchestrations. Similarly, the SEP Ruleset component 512 and SEP Events513 of the foundation layer 510 are shown as configuring the RulesExecution component 542 and the Event Manager component 543 of theorchestration layer 540 respectively.

The horizontal dotted lines 504 represent extension. Extension is theability to customize the product by enhancing existing configuration orreplacing a cross-market component with a market-specific component aslong as the interface remains the same. An example of an extension maybe adding a market-specific step, such as authenticating a shoppingtransaction with a fiscal agency, within a cross-market orchestration,such as checkout. Markets have the ability to augment SEP by configuringtheir own orchestrations, rulesets and events in combination with theirown interfaces and components.

The presentation layer 570 is responsible for enabling the consumptionof multi-step tasks defined as a collection of features, orchestrationand services offered to actors with an intended business benefit. Asdiscussed above, Devices are used by Actors as task-consumptionmechanisms and user-experience endpoints. The presentation layer 570consists of stateless components responsible for supportingdevice-specific rendering and device-specific optimization. Thepresentation layer 570 is also responsible for task delivery to specificdevices. Other responsibilities include the necessary device adapters tosupport any peripherals required by the device such as scales, pin padsand keyboards.

The orchestration layer 540 is a single point of contact for thepresentation layers 570 to invoke conceptual business services, andcoordinate services in support of an activity, such as theorchestration. The orchestration layer 540 can invoke services from anyother layers via the Federated Messaging components 550, manage the unitof work as required by the tasks, trigger context-based rules andcontent-based routing, and raise events based upon rule evaluation. Theorchestration layer 540 is dynamically configurable with cross-marketand market-specific orchestrations, rulesets and events, and it providesrule archetypes in support of Orchestration and Market components. It isalso responsible for handling event subscriptions and notifications. Theorchestration layer 540 has the ability to support synchronous(orchestrations) and asynchronous (events) processing, and also supporta disconnected mode (store and forward, queueing). Orchestrationorganizes services, while events are triggers that result in the passingof information from one component to another. For example, a specificset of services are orchestrated together to perform a transaction. Thecompletion of the transaction, for example, may trigger an event that isrelevant to other systems and services within the SEP. The OrchestrationEngine 541, the Rules Execution Engine 542 and the Event Manager 543 arehosted in the orchestration layer 540.

The federated messaging layer 550 decouples service providers andservice consumers. It also provides infrastructure enablementcomponents, such as, integration among Foundation, Market, Enterpriseand third-party services, brokering, routing, NFR-based brokering(scaling, capacity, etc.), message transformation, and the like.

The foundation layer 510 provides cross-market orchestrations, serviceinterfaces, services and components. Orchestrations may include, forexample, Price Override, Void, Refund, and the like. Service interfacesmay include, for example, Payment, Tax (markets would provide thecomponents), and the like. Services and components may include, forexample, Shopping Basket, Lane Management, and the like. The foundationlayer 510 can also include SEP Administration services 514 that allowmarkets to customize orchestrations, rules and events. The foundationlayer 510 offers persistence via Information Data Services 515, andreal-time event pattern analysis 516. Real-time event pattern analysis516 may include providing support for store management based on variousstore characteristics, such as, high traffic zones, and providing arecommendation engine that enhances customer experiences by analyzingcustomer events and suggesting appropriate actions. The foundation layer510 also provides notification services such as, alerts, reminders,emails, and the like. It also provides transition services thatfacilitate the migration from legacy POS to future products andarchitecture, and it is configurable and extensible by markets.

The market layer 520 provides components as required per interfacesdefined by the foundation layer 510. A user can implement extensions andaugment the SEP via the market layer 520 by adding market-specificorchestrations 521, rulesets 522, and events 523. The market layer 520allows a user to incorporate market-specific components via SEPAdministration 514, and extend or augment SEP data with market-specificdata.

The enterprise layer 530 leverages existing enterprise capabilities andservices, and integrates enterprise operational systems. It can alsoprovide sales data for historical and periodical analytics. Thethird-party layer 580 augments the SEP with third-party products such asTicketmater, and integrate compliance agencies, fiscal entities, and thelike. The security and monitoring layer 560 facilitates user and deviceauthentication, web services security including payload encryption,infrastructure monitoring, capacity monitoring, and traffice re-routing.

Candidate Service Model

The candidate service model may be implemented using a subset of ServiceOriented Architecture Modeling Language (SoaML) which is a UnifiedModeling Language (UML) profile generally useful for modelingservice-oriented architectures. The candidate services may be taggedwith SoaML stereotypes, such as, capability, service interface, andartifact. As discussed above, a candidate service is a self-containedunit of functionality, and multiple candidate services can be combinedto provide a larger functionality, such as, an execution of asales-related task.

Capability stereotype represents a candidate service or candidateservice family that includes the components that implement the services.In other words, both services and service components are both containedwithin the same layer. The service interface stereotype represents aservice or service family interface. In one embodiment, the layerdeclaring the service interface may own and be responsible for thegovernance of the interface, but the component that implements thatinterface may be outsourced to another layer. For example, across-market service interface in the foundation layer, such as the TaxInterface, requires a component in the market layer to deliver thefunctionality. The artifact stereotype represents concepts likepersistence and supplying configuration required by a component such asthe rules engine. The candidate services tagged as artifact may not beservices per se but they may be important characteristics of thecandidate service model.

The orchestration layer may include candidate services, such as, eventmanager (a central repository of event information), orchestrationadministration (a facility that allows configuration of orchestrations,rules and events), orchestration engine (an engine that sequencesservices, evaluates rules, raises events, responds to triggered events),and rules engine. The rules engine is a condition evaluation engine thatsupports external definition of rules and dynamic definition of rulesthat facilitate scenarios such as restricting sales of items when asuspect pattern of sales transactions is observed.

FIG. 6 is a diagram of an exemplary system 600 illustrating variouscandidate services and of the orchestration layer, according to anexample embodiment. System 600 may represent the orchestration layer. Asshown in FIG. 6 , the orchestration layer includes an OrchestrationEngine 610, an Orchestration Administration 620, a Rules Engine 630, andan Event Manager 640. FIG. 6 shows the variables and candidate servicesof each of these components. For example, the Rules Engine 630 consistof a Rule and a Ruleset, and performs the function “evaluate rule” withinputs Rule and Ruleset. The Orchestration Administration 620 configuresthe Orchestration Engine 610, the Rules Engine 630, and the EventManager 640. The Event Manager 640 triggers the Orchestration Engine610, and the Orchestration Engine 610 raises an event in the EventManager 640. The Rules Engine 630 can be triggered by the OrchestrationEngine 610, and raise an event in the Event Manager 640. TheOrchestration Engine 610 evaluates the pre-conditions before calling aservice.

The Rules Engine 630 can perform or be responsible for variousfunctionalities. These functionalities include specifying a ruleassociated with a sub-task in a multistep commerce-related task. Thesub-task can be implemented as a separate sub-task data structure thanother sub-tasks in the multistep commerce-related task and the rule canbe implemented as a separate rule data structure than the separatesub-task data structure. When the multi-step commerce-related task isexecuted, the Rules Engine 630 can trigger the rule in response. TheRules Engine 630 can analyze information generated in response to theexecution of the multi-step commerce related task to determine whetherthe rule has been satisfied. The Rules Engine 630 further determineswhether to continue executing the multi-step commerce-related task basedon a determination of whether the rule has been satisfied. If the rulehas not been satisfied, then the Rules Engine 630 may abort themulti-step commerce-related task, or abort the sub-task associated withthe rule.

Triggering a rule may invoke the rule as a separate task within thesub-task. One may modify the rule by changing the rule data structure,and modifying the rule may alter the multi-step commerce-related taskwithout modifying the sub-tasks of the multi-step commerce-related task.Additionally, modifying the sub-task by changing the sub-task datastructure to modify the multi-step commerce-related task, may be donewithout modifying the rule data structure. One example of a rule iswhere the rule invokes actions or events based on a bin number of acredit card that is used to make a payment or complete a salestransaction. Another example of a rule may prompt an actor, such as acustomer-facing associate, via a graphical user interface, to query acustomer.

FIG. 7 is a diagram of a system 700 illustrating interactions betweenvarious candidate services of the architectural layers of the SEP,according to an example embodiment. System 700 includes a presentationlayer 710, an orchestration layer 720, and a foundation layer 740. Thepresentation layer 710 invokes an orchestration 724 to perform amulti-step task. An “orchestration” is a mechanism to invoke services ina particular sequence in support of a multi-step task. System 700 inFIG. 7 illustrates orchestration 724 for a checkout task. In oneembodiment, orchestrations 724 are configured within the orchestrationengine 722. The orchestration 724 invokes various candidate services 742to fulfill the task. Both the orchestration 724 and the candidateservice 742 can trigger an event 728. The event 728 may be configuredwithin the event manager 726. The orchestration 724 may request therules engine 734 to evaluate a rule. Event administration 744 maysubscribe to an event 728, and the event manager 726 may notify thesubscriber 730 as discussed below in connection with the push and pullmodels. The pattern analysis component or service 746 observes a topic732 and triggers an event 728 when appropriate. The candidate services742 can be in any layer. Even though FIG. 7 illustrates invocation of afoundation candidate service 742, it should be understood that candidateservices of other layers can be invoked. Pre-conditions refer toentities required as inputs to the orchestration steps whilepostconditions refer to the required outputs from the orchestrationsteps. The orchestration engine 722, as having the responsibility tomaintain state, tracks these entities in its Session Container.

The rules engine 734 include reconfigurable rules 736 that can beassociated with an execution of the services 742, also referred to assub-tasks, such that the rules 736 can be called in response toexecution of the one or more services 742. The rules 736 can be modifiedwithout modifying the services 742 and the service 742 can be modifiedwithout modifying the rules 736. Some examples of rules 736 includeproviding rewards or discounts based on the bin number of a credit/debitcard, prompting a cashier to ask a customer if they are interested inpurchasing a featured item, rules to handle different payment options.In an example embodiment, the modular implementation of the rules andthe services permits modifications of one with affecting the other.

For example, a “get personalized coupons” orchestration may include thefollowing candidate services and conditions:

Pre Conditions Service Post Conditions Customer CredentialAuthorization.getIdentityFor( ) Customer Identity Customer IdentityCustomer.lookUpCustomerProfile( ) Customer Profile Customer ProfileCoupons.getCouponsFor( ) Coupon[ ]

One distinction between orchestrations and events is that synchronousactivities are handled via the Orchestration Engine 722 whileasynchronous activities are handled via the Event Manager 726.Orchestrations 724 can evaluate rules 736 and trigger events 728 as aresult. Candidate services 742 can also evaluate rules 736 and triggerevents 728. In some embodiments, orchestrations 724 can bemulti-threaded so long as there are clear and configurable split andjoin steps in the orchestration.

In an exemplary embodiment, an Event Manager supports various models ofoperations. In some embodiments, the Event Manager supports a pull modelor a push model. In alternative embodiments, the Event manager supportsboth a pull model and a push model. The pull and push models are namedfrom the perspective of an event consumer. In an example push model, theEvent Manager is responsible for pushing notifications to interestedparties. The SEP Administration feature in the foundation layer supportssubscription to events. Subscriptions require orchestrations that areinvoked upon event triggering. The push model of event notificationsupports near real-time processing. It is intended to support scenarioswhere the occurrence of an event requires immediate attention. As suchwhen the Event Manager sees this event, it knows to invoke thisorchestration right away.

In an example pull model, the Event Manager is responsible forpublishing the event to a topic or a context group. A topic or a contextgroup may be used interchangeably in the present disclosure. A topic ora context group refers to events or groups of events triggered, forexample, during a completed sales transaction, such as a sale of arestricted item. Other examples of topics or context group includesevents relating to a transaction that resulted in a refund, or a seriesof successive financial transactions that indicate a possibility offraud. An event-driven system, such as the SEE, allows for dynamism ofsuch events. Components or candidate services can observe a topic orcontext group (i.e., pull the event information) and decide whether toinvoke orchestrations or trigger additional events. This facilitatesrequirements like Anti-Money Laundering, Fraud, and the like. The pullmodel supports asynchronous processing. Event consumption can happen atspecified intervals. In some embodiments, event consumption may notoccur if there are no observers of a particular topic. The EventManager's responsibilities end when the event is published to thetopic(s). In an example embodiment, an event is kept in a topic for aperiod of time that may be a configurable parameter. In an alternativeembodiment, an event may be in kept in a topic for a predetermined timethat is not configurable by users.

The federated messaging layer may include candidate services such asenterprise messaging, federated messaging, message categories, storemessaging, and transformation services. The enterprise messagingcandidate service includes the messaging components that connect a storeto the enterprise such as a data center. The federated messagingcandidate service is the messaging interface that encapsulates the StoreMessaging and the Enterprise Messaging components. This is a unifiedinterface for service consumption. Service consumers are unaware of theservice provider's location (for example, local, store or a datacenter). All service communications go through this Messaging interface.The message categories candidate service is the classification ofmessages with considerations for security, affinity to orchestrations,and service level agreements. The message categories may include, butare not limited to, shopper, shopping, catalog, payment, ordering,documents, store, SEP Admin, and general. The store messaging candidateservices is the messaging layer that addresses the services that areexecuted in the store. The transformation service is the layer thattranslates between a store's standard rule model and various standardsused by the vendors.

The foundation layer may include configurations such as SEPOrchestration, SEP Events, and SEP Rulesets, that allow forreconfiguration of foundations services that affect multiple Marketswithout impacting other services. SEP Orchestration configurationfacilitates execution of services in sequential order to complete a unitof work needed by the presentation layer. SEP Events configurationprovides asynchronous ability to notify interested parties that acertain service has occurred or a context exists. For example, acustomer buys an item that is restricted due to Anti-Money Launderingrequirements and it may result in a denial of sale next time thatcustomer makes a purchase. In that case, the SEP Events configurationmay notify the cashier that the sale to that customer must be denied.SEP Rulesets configuration provides the ability to apply a set of rulesto a specific context of the entities. For example, an attempt to buy analcoholic item from an underage associate, results in a denial of salebecause alcohol cannot be sold by an underage associate. In anotherexample, an attempt to buy alcoholic item on Sunday at a store that islocated in a district that does not sell alcohol on Sundays, results ina denial of sale because alcohol cannot be sold at the store on Sundays.

The foundation layer may include the following candidate servicesdescribed below. SEP Administration service is the ability to createunique settings for orchestrations, events and rules within the contextof the entities that have been declared. Cash Office service refers tothe operational area of the store which deals with all salestransactions and payments to assure compliance with store policies. Itemservice handles the goods or services that are sold to customers throughsuppliers. Shopping Basket service is the collection of items thecustomer is looking to purchase and which has some level of assurancethat a sale can be completed. Real-time Pattern Analysis service is theability to identify a sequence or collection of events and initiate anorchestration to meet the needs of the business.

Notification service is responsible for the delivery of a message to anassociate or customer. Sales Transactions service is the purchase ofmerchandise from the store, which the customer is taking delivery of atthe moment. Audit service is the tracking of actions which can later beused as proof of compliance. SEP Information Data Services arepersistence services used to assure all information is not lost if thesystem fails. Reports services is information used by management tosupport business decisions. Lane Management service is the tracking ofthe queue depth in each lane to assure stores are providing customerswith a satisfactory shopping experience. Device Management service isthe tracking of devices used in the store by associates and the uniquecollection of devices needed by the associates to perform specifictasks. Store services is the location where the store does business withits customers. Document Generation service is the ability to print areceipt or third-party documents needed by customers.

The market layer may include such as market orchestration, marketevents, market rulesets, and the like, that allow customizations formarket-specific behaviour without code changes. Market orchestration ismarket specific execution of services in a sequential order to completea unit of work needed by the presentation layer. Market events refers toa market's asynchronous ability to notify interested parties that acertain service has occurred or a context exists. For example, acustomer buys an item that is restricted due to Anti-Money Launderingrequirements which may result in a denial of sale next time thatcustomer makes a purchase. In this case, market events notifies thecashier that the purchase must be denied for that customer. Marketrulesets refers to a market's ability to apply a set of rules to aspecific context of the entities. For example, an attempt to buy analcoholic item from an underage associate, results in a denial of salebecause alcohol cannot be sold by an underage associate. In anotherexample, an attempt to buy alcoholic item on Sunday at a store that islocated in a district that does not sell alcohol on Sundays, results ina denial of sale because alcohol cannot be sold at the store on Sundays.

The market layer may facilitate the following SEP extensions describedhere. Payment extension is a record of the use of a payment instrumentto complete the sales transaction for merchandise. Availabilityextension is the query of inventory needed to assure a store's abilityto complete a purchase from the customer. Market Data Services extensionis the ability to persist market information despite the failure of thesystem. Market Data extension is the information needed by marketservices to complete the unit of work needed by the business. Taxextension is the tax that is collected for the sale based on specificgovernment jurisdictional regulations, and may be based on multiplejurisdictions (city, county, state, federal, export, VAT, etc.) and mayinclude multiple taxes on merchandise (sales tax, soda tax, etc.). Feeextension is the charge on purchasing an item that reflects the cost ofactivities associated with the purchase that local governments engagein. Fee extensions often reflect things like local disposal of batterieswhich occur as a result of a purchase.

Coupon extension is the ability to support reducing the cost of an itemto the consumer through a manufacturer reimbursement. Discount extensionis the reduced amount being charged for an item because of somepromotional event. For example, the promotional event may be anassociate discount. Store Task extension is a unit of work that needs tobe assigned and completed by an associate in a specific timeframe.

The market layer may also include the following candidate servicesdescribed here. Bill Pay service is the collection of payment for thepurpose of completing the debt obligation of a consumer and a vendor.Fuel service is the service that collects payment for specific fuels andnumber of gallons (or liters) of fuel purchased. Pension/RetirementAccount service are the services which allow customers to withdraw moneyand check the balance of a customer pension account. Check Cashingservice is the service that handles payout of a check against a specificbank account. Currency Exchange service is the service that allows acustomer to exchange one set of currencies for another set ofcurrencies. Bank Account service is the consumer account where the moneyis stored for later use in purchases. Store service is the specificstore services needed by local markets to stay competitive in thebusiness.

The enterprise layer may include the following candidate servicesdescribed here. Customer Profile service handles the preferences aspecific customer may have opted into that enables a store to createvalue in their sales experience with the store. Customer Account serviceis the record of the service or agreement to do business. Prospectservice relates to future customers that the store wants to encourage toshop at the store. Membership service is the service which allows acustomer to purchase merchandise at a club store, where a customer mustbe member to shop. Address service is the postal location where mail isdelivered to. Authorization service is the service which takes acredential used to identify a person and authorizes them to use aresource. List service is the service around managing a collection ofitems. Gift Card service handles the special payment type in which moneyhas been given as a gift to enable a desired purchase.

Workforce service is the collection of associates who assist in carryingout the store business. Complaint service is the formal declaration ofan issue that needs to be addressed. Catalog service is the collectionof products and hierarchies to enable presenting the assortment ofmerchandise for sale. Restriction service is the sales or paymentrestriction that specifies what can be purchased with what types ofpayments. Recommendations service is product selections the customer maybe interested in based on prior comments from other customers. Itemservice is the merchandise to be purchased which can be either a good ora service. Price service is the cost of an item to a consumer. Claimsservices is the vendor reimbursements stemming from a customer return ordamage merchandise which can no longer be sold. Inventory service is alist of merchandise and quantities that are available to be sold.

Private Label Credit Account service are services around providingcredit to customers for purchases with the store. Returns service areservices around returning an item and receiving a refund. Money Transferservice are services around collecting money at one location anddelivering it at another location for a specific person. UniversalBasket service is a collection of merchandise the consumer wishes topurchase, independent of the specific channel the merchandise isfulfilled through. Customer Order service are services around sellingmerchandise from supply chains and delivered as they desire.

Component Model

In some embodiments, a component model is used to implement thefunctionalities of the SEP. The component model facilitates structureand modularity of various software components. It aides designers anddevelopers in understanding the high level system design. Eacharchitectural layer is tagged with a “subsystem” stereotype. FIG. 8 is adiagram of an exemplary system 800 illustrating an example componentmodel and the interactions and dependencies between each layer,according to an example embodiment. As shown in FIG. 8 , system 800includes various architectural layers, discussed herein, tagged assubsystem stereotype. These layers may include a presentation layer 820,an enterprise layer 830, a foundation layer 840, an orchestration layer850, a federated messaging layer 860, market layer 870, and third-partylayer 880. The architectural layers include capabilities and/or serviceinterfaces as discussed above. System 800 also includes devices 810 thatmainly interact with the presentation layer 820. The arrows illustratethe interactions between the layers.

Component Interactions

The following description discuss example high-level interactions froman end user perspective. Security measures, such as encryption andsecure protocol, are implemented as appropriate, even though thesemeasures are not specifically discussed in connection with the exampleinteractions below.

FIG. 9 illustrates computational components 900 configured to perform asales process within the SEE, according to an example embodiment.Components 900 include various components that perform the necessarysteps to complete a sale. These components are Add Items to the Basket901, Personalized Coupons 902, Total Order 903, Collect Payment 904, andRecord the Sale 905. Some of these components may be triggered by a“Checkout” request from a customer device or a customer-facing associatedevice.

FIG. 10 is a chart of an exemplary process 1000 illustrating the “AddItems to the Basket” component of the high-level sales processillustrated in FIG. 9 , according to an example embodiment. The linesillustrate the sending and receiving entities for information andrequests. The solid lines represent requests for execution of a step orperformance of appropriate actions. The dotted lines represent aresponse to the request signaling that the execution or performance iscompleted.

Process 1000 begins with a device 1010 requesting to add an item byinitiating “execute (#addltem),” where #addltem is the item to be added.This request is forward to the Orchestration Engine 1020, whichorchestrates the appropriate components and candidate services tocomplete the “execute (#addltem)” 1.0 request. The Orchestration Engine1020 forwards “add (Offering)” 1.1 to capability Shopping Basket 1040.While executing “add (Offering)” 1.1, a rule is triggered. ShoppingBasket 1040 forwards “evaluate rule (#isItemRestricted)” 1.1.1 tocapability Rules Engine 1030, where #isItemRestricted is the rule to beevaluated. The #isItemRestricted rule can be used to determine whetheran item in the Shopping Basket 1040 has any sales restrictions andwhether the sales restrictions have been satisfied. For example, thesale of an item can be restricted based whether the customer hassatisfied a minimum age requirement for the item, whether the customerhas a prescription for the item, whether the customer has a permit forthe item has a permit, or may be restricted for other reasons. RulesEngine 1030 executes “evaluate rule” 1.1.2 with input #isItemRestricted,and forwards the result to Shopping Basket 1040. Shopping Basket 1040realizes the next step is to “execute (#getDiscountFor)” 1.1.3, andforwards the request to the Orchestration Engine 1020. In response, theOrchestration Engine 1020 initiates the appropriate orchestration. Inthis case, the Orchestration Engine 1020 calls the service interfaceDiscount 1060, and forwards “getdiscountfor (Item)” 1.1.3.1, where Itemis the item for which the discount is to be calculated. The serviceinterface Discount 1060 completes the request and forwards the output tothe Orchestration Engine 1020. The Orchestration Engine 1020 thenforwards an “execute” 1.1.4 request to Shopping Basket 1040, which letsthe Shopping Basket 1040 know to continue its process and that theprevious request “execute (#getDiscountFor)” 1.1.3 has been completed.In some embodiments, the Orchestration Engine 1020 may also forward theoutput of the completed request, in this case, the discount for theitem, to Shopping Basket 1040. The next step according to ShoppingBasket is “execute (#getFee)” 1.1.5. This request is forwarded to theOrchestration Engine 1020, and in response, the Orchestration Engine1020 calls the service interface Fee 1070 and forwards the request toit. Service interface Fee 1070 completes the request and forwards theoutput 1.1.5.2 to the Orchestration Engine 1020. The OrchestrationEngine 1020 then forwards an “execute” 1.1.6 request to Shopping Basket1040, which lets Shopping Basket 1040 know that the request “execute(#getFee)” 1.1.5 has been completed. In some embodiments, theOrchestration Engine 1020 may also forward the output of the completedrequest, in this case, the fee for the item, to Shopping Basket 1040.

The next step according to Shopping Basket 1040 is “execute(#CalculateSalesTax)” 1.1.7. Shopping Basket 1040 forwards this requestto the Orchestration Engine 1020, which in response, calls serviceinterface Tax 1050 and forwards the request 1.1.7.1 to it. ServiceInterface Tax 1050 completes the request and forwards the result to theOrchestration Engine 1020. The Orchestration Engine 1020 then forwardsan “execute” 1.1.8 request to Shopping Basket 1040, which lets ShoppingBasket 1040 know that the request “execute (#CalculateSalesTax)” 1.1.7has been completed. In some embodiments, the Orchestration Engine 1020may also forward the output of the completed request, in this case, thetax for the item, to Shopping Basket 1040. All steps being completed,Shopping Basket 1040 forwards “add” 1.2 to the Orchestration Engine 1020letting it know that step “add (Offering)” 1.0 is completed. TheOrchestration Engine 1020 forwards “execute” 2.0 to device 1010 lettingit know that the request “execute (#addltem)” 1.0 is completed.

Similar to the “Add Item to the Basket” component, the other componentsof the high-level sales process shown in FIG. 9 execute variousfunctions by interacting with various layers, candidate services, andservice interfaces to deliver the a part of the sales process. Forexample, the “Record the Sale” component begins by requesting theOrchestration Engine to “execute (#recordTheSale).” The OrchestrationEngine initiates the appropriate orchestration, where the first step isto “print receipt.” The “print receipt” request is sent to capabilitySales Transaction. Sales Transaction requests the Orchestration Engineto initiate the appropriate sub-orchestration for “print receipt.” Thefirst step of the sub-orchestration routine is to request “create(#localReceiptTemplate, Sales Transaction, xml)” to capability DocumentGeneration. Document Generation sends back “create” to the OrchestrationEngine letting it know that it has completed the request. TheOrchestration Engine sends an “execute” signal to the Sales Transactionletting it know that it has completed the “execute (#printReceipt)”request. Sales Transaction sends a “print receipt” signal to theOrchestration Engine letting it know that it has completed the “printreceipt” request. Since all steps are completed in the orchestration,the Orchestration Engine sends a “execute” signal to the requestingentity letting it know that it has completed the “execute(#recordTheSale)” request.

In this manner, the Orchestration Engine is responsible for initiatingthe appropriate orchestration based on the request from an entity. Theinitiated orchestration may include sub-orchestrations within it thatthe Orchestration Engine is responsible for orchestrating so that therequest is completed. As the above discussion illustrates, to completethe request “execute (#recordTheSale)” the Orchestration Engine has toorchestrate “print receipt” which includes orchestrating asub-orchestration “create (#localReceiptTemplate, Sales Transaction,xml).” After each orchestration is completed, the completing componentsends a signal back to the requesting component that it has completedthe steps in the orchestration. Referring back to the “Add Items to theBasket” component, the main orchestration orchestrated by theOrchestration Engine is “add (Offering),” which required theorchestration of sub-orchestrations such as “execute (#getDiscountFor),”“execute (#getFee),” and “execute (#CalculateSalesTax)” as requested bythe capability Shopping Basket.

Persistence Model

The persistence model refers to a model that dictates where thetransaction ‘lives,’ or is stored or active, while other components andsystems are acting upon on it or interacting with it. This model alsodictates which component or system is responsible for and tracking dataduring the occurrence of a transaction. In some embodiments, theorchestration engine is responsible for tracking data, however, the datamay need to be persisted or made available at a product instance levelor a service level. Traditional POS systems focus on transacting saleswhile providing customer experiences such as convenient payment choicesand fast checkout. One of the benefits of the SEE is the expansion frommere ‘purchasing’ to inclusion of ‘shopping’ by providing capabilitiesbeyond payment and checkout. Such capabilities may exert greaterinfluence on the overall shopping experience and enable techniques suchas up-sell, cross-sell, omni-channel, endless aisle, social connectionsfor recommendations, and others. Up-sell refers to a sales techniquewhereby a seller induces a customer to purchase more items, upgrades, oradd-ons in an attempt to make a more profitable sale. Up-sell ofteninvolves marketing more profitable services or products and can alsoinclude exposing the customer to other options that he or she may nothave considered. Cross-sell refers to a technique involving sellingamong or between clients, markets, traders, and the like. It may alsorefer to the practice of selling an additional product or service to anexisting customer. Omni-channel selling refers to the technique ofinfluencing customer experience through all available shopping channels,such as, mobile devices, computer devices, brick-and-mortar stores,television, radio, postal mail, and the like. In omni-channel technique,a customer may use all channels of shopping simultaneously, and theseller may track the customer's activities across all channels. Endlessaisle refers to the concept of using in-store kiosks to allow customersto order products that may not be able in that particular store.

To implement the expansion to shopping, in an example embodiment, theSEE consists of a persistence component model. The persistence componentmodel is based on three major notions: Shopping Basket 1120, CustomerOrder, and Sales Transaction. FIG. 11 is a diagram of an exemplarysystem 1100 illustrating a persistence component model, according to anexample embodiment. The Shopping Basket 1120 is a container ofpersistent entities that may be passed to and from SEP instances as wellas to and from integrated systems while payment has not occurred. In oneembodiment, the SEE, regardless of the origins of the Shopping Basket1120 itself, can accept a basket, total it, collect payment and recordthe sale. The Shopping Basket 1120 along with Events 1134, Rule 1133,Tax 1130, Discount 1132 and Coupon 1131 are the concern of ServicePersistence 1110. In particular, these entities cover persistence needsduring shopping activities such as adding items to the basket,calculating discounts based on the items in the basket and transferringa Shopping Basket 1120 from one device to another. For example, acustomer may use a Smartphone to scan items and pay for them at aself-checkout register. As services collaborate during a shoppingorchestration they may share or exchange a Shopping Basket 1120.

Shopping Basket 1120 contains the Items 1121 along with their Price 1122at the time the Item 1121 is added to the Basket 1120. In an exampleembodiment, the price may expire after a reasonable price expirationperiod. In a Shopping Basket 1120, Items 1121 may not affect inventorylevels because the customer has not yet purchased the Items, but hasonly expressed the desire to purchase the Items 1121. However, the Items1121 in the Basket 1120 may carry with it an availability-to-promisefunction through a specific fulfilment node. An availability-to-promisefunction provides a response to customer order inquiries based onresource availability. Shopping Basket 1120 is uniquely identified bytheir Session 1126, Security Token 1127 and/or Customer entities 1125,with Customer 1125 being an optional entity to accommodate a Shopperpurchasing without Customer Credentials. As compared to SalesTransactions 1150 and Customer Orders 1170, Shopping Baskets 1120 aretemporary. The Shopping Basket 1120 is no longer needed once the paymentor intent-to-pay event takes place because when a payment is made, aShopping Basket 1120 is used to record a Sales Transaction 1150. Whenthe customer declares an intent to buy but defers payment, the ShoppingBasket 1120 is used to create a Customer Order 1170, thus, eliminatingthe Shopping Basket 1120. Furthermore, Shopping Baskets 1120 containPrices 1122 which may fluctuate, and consequently, they expire ifpayment or a commitment to pay does not occur after some reasonableperiod of time.

Discounts 1123 and Coupons 1124 may be applied as Items 1121 are addedor removed from the Shopping Basket 1120. However, during the totalingof the basket they may be re-evaluated for their applicability andvalidity. Calculating the total of the Shopping Basket 1120 may occur atany point in time and not just at the time of payment. Rules 1133 mayalso be applied, but not enforced, as Items 1121 are added to theShopping Basket 1120. Rules 1133 may only be enforced at the time ofcheckout. Various services may collaborate with Event Manager as eitherevent producers or event consumers. Events 1134 decouple services duringthe sales activities and improve customer experience. For instance, aservice adding an item to the basket by scanning can trigger thestart-scan and end-scan events. Another service that measures deviceperformance can calculate and record the elapsed time between the startand end scan events, and yet another service that measures storeperformance can aggregate the elapsed times across all scanners todetermine device efficiency. By not waiting for the consuming servicesto do their work, the triggering service can provide a better customerexperience.

Customer Order 1170 is created from Shopping Basket 1120 when Customer1125 expresses intent to buy but defers payment, or when a ShoppingBasket 1120 contains Items 1121 that are to be fulfilled outside of thestore. Taxes 1130, Discounts 1132, and Coupons 1131 are applied at thetime this transition takes place. Unlike Items 1121 in the ShoppingBasket 1120, Customer Order 1170 affects inventory levels because thereis a commitment to fulfil the Customer Order 1170 in exchange for acommitment to pay for the Items 1171. There are additional entities thatare tracked with Customer Order 1170. First, the Audit entity 1177represents a permanent record of a business event of interest, such asconfirmation that a restricted item met the appropriate criteria at thetime of payment. Second, Payment Instrument 1178 and Payment 1179 aretracked with Customer Order 1170 either when a partial payment is made(i.e., a layaway scenario) or when a full payment takes place. Incontrast to Shopping Basket 1120, Customer Order 1170 is a permanentrecord. As such, they support the ability to track Customer Orderhistory. Customer Order 1170 supports the ability of adding Items 1171,removing unpaid items and returning/refunding paid items. As such,Customer Order 1170 is said to be mutable.

Sales Transaction 1150 is the final, permanent representation of a sale.Consequently, ownership of the items in the basket is transferred to theCustomer 1156 at the time of the transaction. Sales Transaction 1150also tracks pertinent information about the sale such as Associate,Store, Lane, Register, and the like. Like Customer Order 1170, SalesTransaction 1150 decreases inventory and supports the ability to trackhistory. Unlike Customer Order 1170, Sales Transaction 1150 isimmutable—once recorded it cannot be altered.

Store Deployment

Store deployment profiles refer to the different ways instances of theSEP and SEE are made available to the Actors. Devices within the SEEhave a degree of connectivity required to operate as well as a thicknessof the device. The degree of connectivity refers to how much work adevice needs to support when disconnected from a network (enterprise orstore). The thickness of the device refers to the services andcomponents that need to be deployed onto a device, including dedicatedhardware, to deliver the sales-related tasks to an actor. Based on thesecharacteristics, various deployment profiles may be available within theSEE. In an example embodiment, at least nine deployment profiles areavailable. These profiles may include Brazil POS, Assisted Checkout,Self-Checkout, ASDA Popup Store, Vending Machine, Mobile Single-Channel,Mobile Multi-Channel, Cloud Popup Store, and Cloud Register.

While some devices may be designed to work offline (as is the case withthe Brazil POS), many others may support varying levels of operation ina disconnected mode for varying reasons. Based on services and componentlocations stemming from these requirements, the deployment profiles mayspan over four deployment zones, such as Device (any profile shown inthis zone implies some presence of components and services on the deviceitself), Store (profiles in this zone implies presence of components andservices on the store network/infrastructure), Enterprise (profiles inthis zone implies presence of components and services on the enterprisenetwork/infrastructure), and External (profiles in this zone impliespresence of components and services on a network/infrastructure outsidethe enterprise).

Some of these profiles require store-and-forward capabilities that allowfor processing sales transactions locally (i.e., the device) and latersynchronizing them back to the store. Store-and-forward support may bethe responsibility of the Federated Messaging Layer, implying that somemessaging components may need to be deployed on the device.Synchronization can be enabled by, for instance, Device ManagementServices at the store initiating an orchestration upon detecting acheck-in event from the Device.

FIG. 12 is a chart 1200 illustrating the various deployment profileswithin four deployment zones based on a degree of connectivity andthickness of the device, according to an example embodiment. Someprofiles are shown as covering multiple deployment zones to recognizethe potential need to deploy services locally for performance reasons.For example, an enterprise service like Price may be deployed at theStore to avoid the latency inherent with communications to the globaldata centers. As shown in FIG. 12 , the deployment profiles may includea Brazil POS profile 1210, an Assisted Checkout profile 1220, aSelf-Checkout profile 1230, a ASDA Popup Store profile 1240, a VendingMachine profile 1250, a Mobile Single-Channel profile 1260, aMulti-Channel profile 1270, a Cloud Popup Store profile 1280 and a CloudRegister profile 1290.

The Brazil POS 1210 can be a deployment profile specific for POSterminals in Brazil. The Brazil POS 1210 deployment profile includesstore-and-forward capabilities, and compile-time orchestration is builtinto the software package(s) running on the device. Because thisdeployment profile is capable of limited sales transactions even when adevice is disconnected from the store, many of the components aredeployed in both the Device and the Store. The normal mode of operation,assuming performance criteria is acceptable, is connected to the store.Failover mode is to the device components. While the Brazil POS 1210deployment profile is described herein as a non-limiting example, thoseskilled in the art that deployment profiles can be created for othercountries, regions, towns, states, cities, or any other geographicalareas.

The Assisted Checkout 1220 and Self-Checkout 1230 deployment profilesrepresent common POS devices at the checkout lane. Both are similar inoperational characteristics but each profile supports a different set oftasks and device peripherals. These profiles support dynamicconfiguration of orchestrations to allow adaptability with minimaldisruption to store operations. However since these devices need to beable to complete Sales Transactions even in case of outages,configuration changes need to be made centrally (at a Store server forexample) and then pushed out to the devices. This requires collaborationbetween SEP Administration and Device Management services. Localdeployment and co-location of Orchestration, Foundation and Marketservices is likely in these profiles. In some embodiments, theseprofiles may include store-and-forward capabilities in support offailover scenarios.

The ASDA Popup Store deployment profile 1240 includes compile-timeconfiguration and is designed to run limited sales transactions whiledisconnected. In this profile, services and data deployed on the devicerequire that the device downloads any data needed to operate the deviceprior to leaving the store (for example, catalog and pricinginformation). Local deployment and co-location of Orchestration,Foundation, Market and Enterprise services may be required to the extentdemanded by the sales-related multi-step tasks in the Product Instance.This profile also includes store-and-forward capabilities. The ASDAPopup Store profile 1240 is one of the lightest profile, in terms ofinfrastructure. It relates to situation, for example, where a user isable to use the SEE on a network connected device within an emptybuilding, without any other infrastructure available to the user.

The Vending Machine deployment profile 1250 is representative of acommon kiosk at the store. This profile includes compile-timeorchestration for single-purpose devices designed around a limited setof orchestrations and products. Dynamic orchestration for multi-purposekiosks may be included. Store-and-forward capabilities are included tosupport services and components deployed on the device for disconnectedoperations. In some embodiments, this profile may include localdeployment and co-location of Orchestration, Foundation, Market andEnterprise services. Furthermore, this profile may be integrated withEnterprise or Third-Party Services.

The Mobile Single-Channel 1260 and Multi-Channel 1270 deploymentprofiles include compile-time orchestration. These profiles are similar,except for the Multi-Channel profile represents a superset of taskssupported by the Single-Channel profile, and the Multi-Channel profilemay access more Enterprise Services than the Single-Channel profile.Furthermore, the Multi-Channel profile supports a greater assortment ofmerchandise than the Single-Channel profile. Foundation or Marketservices may be locally deployed and co-located in the Device to enhancecustomer experience.

The Cloud Popup Store 1280 and Cloud Register 1290 deployment profilesinclude dynamic orchestration and requires highly availableinfrastructure. In some embodiments, only the Presentation Services aredeployed to the device.

Market Innovation

Market extensions are supported by the SEE as discussed above. Forexample, a Market entity wants to introduce personalized coupons toselect customers, then first an SEP Administrator configures the newPersonalized Coupon orchestration, rules and events according to theMarket entity's task. The new rules are added to the SEP Ruleset,“isCustomerAccountActive” rule is configured, “isBusinessMember” rule isconfigured, and a new event to the Event Manager configuration isdefined. A Personalized Coupon orchestration is added with the followingcandidate services and conditions:

Pre Conditions Service Post Conditions Customer CredentialAuthorization.getIdentityFor( ) Customer Identity Customer IdentityCustomer.lookUpCustomerProfile( ) Customer Profile Customer ProfileCoupons.getCouponsFor( ) Coupon[ ]

Presentation Services can then invoke the an orchestration calledPersonalizedCoupons that handles personalized coupons. The OrchestrationEngine calls the services in the sequence specified by theconfiguration. Pre-conditions must be present in the Session Containerbefore calling a service. Post-conditions are results that theOrchestration Engine puts in the Session Container upon completion of aservice. The Coupon component evaluates the pertinent rules from the SEPRuleset, and calls the Third-Party Coupon Vendor service via theFederated Messaging component, which has been configured to route therequest for this service according to a vendor agreement.

Interaction Architecture Approach

Integration of service components both internally within SEE andexternally with other systems, third-parties and vendors are provided bythe Orchestration and Federated Messaging layers with security controland monitoring supported by the Security and Monitoring layer. Theintegration domain within the SEE consists of vendor products offeringnative and/or customized interfaces and services, and custom developedinterfaces and services. The integration domain with systems andservices external to SEE consists of market facing and enterprise facinginterfaces and services. For both integration domains, in an exampleembodiment there is support for at least three integration types: Onlinefor realtime and near real-time scenarios, Batch for bulk processingscenarios, and Offline for disconnected scenarios, such asstore-and-forward and popup stores.

Any number of combinations among these integration types is provided tosupport various devices, environments and operational requirements undervarious scenarios. The sequencing and matching of pre-condition andpost-condition of services in support of these integration types ishandled through a combination of Orchestration and Federated Messagingcomponents. The Federated Messaging layer is responsible for providingthe linkage between primary and secondary (or more backup sites ifappropriate) connections to, and invocation of, services in a mannerthat is transparent to service requesters. This layer also providesmessage transformation and broker services with its integration tools.

Online Integration

Real-time integration is coordinated by the Orchestration Engine andsupported by the Federated Messaging components. Near real-timeintegration requires collaboration with the Event Manager as describedabove in the Orchestration Layer responsibilities. In any case, theMessaging layer is responsible for carrying the payload information.

An orchestration consists of one or more services executing in apredictable sequence. The control of the sequence of execution of theconstituent services in an orchestration is defined using OrchestrationAdministration and is supported with rules. An orchestration can beinvoked when an event occurs and can in turn generate additional events,supporting from the simplest service call to very complex aggregationsof service calls. As discussed above, to invoke an orchestration as aresult of events occurring there are two choices: subscriptions (pushmodel) and topics (pull model). In general, when an event is triggeredfrom an event producing service or orchestration in the Foundation,Market or Orchestration layers, the Event Manager in the Orchestrationlayer is responsible for persisting the event in the Event Repository,publishing the event in the appropriate topics or context groups (insupport of the pull model), and notifying subscribers by invoking theconfigured orchestrations (in support of the push model).

Push Model

FIG. 13 is a diagram of an exemplary process 1300 illustrating examplesteps of a push model, according to an example embodiment. In an examplepush model, an administrator using the SEP Administration services inthe Foundation layer 1310 subscribes to events with call backsrepresenting Event Consumer Orchestrations in the Orchestration layer.When the event is triggered, the Event Manager 1330 notifies subscribersand invokes corresponding available Event Consumer OrchestrationServices 1320 asynchronously. The push model is useful when thetriggering of an event requires immediate attention. The push modelfocuses on decoupling orchestrations, as in decoupling checkout frommonitoring restricted items in order to detect a pattern of concern, forexample. For instance, a purchase of a restricted item (for example, ameth ingredient) occurs. The ‘restrictedltem’ event is triggered duringcheckout orchestration, capturing additional event data such as whichpayment instrument was used to transact and by whom. The Event Manager1330 triggers an orchestration designed to create a rule to block/warnsales of this item at local stores within a radius of certain miles, sothat the customer may not buy additional quantities of the restricteditem. In this example, the design intent is to balance a fast checkoutexperience to the shopper with the need to monitor sales of restricteditems. However, the shopper does not pay a performance price while thepattern analysis components do their work.

Pull Model

FIG. 14 is a diagram of process 1400 illustrating example steps of apull model, according to an example embodiment. As in the push model, anoccurrence of an event or a triggered event from an event comes from anorchestration or service in the Foundation or Market layers 1410. Theevent consumption is different however; the responsibility of the EventManager 1420 ends with the publishing of events to the topic(s) orcontext group(s). Rather than the Event Manager 1420 invokingorchestrations as per the configuration, Event Observer 1430 in theFoundation or Market layer 1410 monitors events as they are published tothe different topics. When the Event Observer 1430 sees a specific eventof interest in the topic or the context group, or a pattern is detected,it may trigger additional events or invoke an orchestration in theOrchestration layer 1440. For example, a Fraud Detection Observer wouldmonitor events in the Sales Completed topic. If a suspicious pattern isdetected, it triggers a ‘potentialFraud’ event which in turn initiatesan appropriate orchestration.

Batch Integration

The Batch mode of integration is suitable when there is a collection ofevents or data records to be processed by a service, and theaccumulation of data records before processing is a natural businessprocess. In certain embodiments, processing a series of data recordstogether is an optimum way to handle a large number of records. Thebatch (or block) processing can be triggered by a time (schedule) eventor situation (condition) event. A sequence of records can be deliveredfrom one SEE component to another by the Federated Messaging layer. TheFederated Messaging layer is responsible for sending the records insequence or in parallel from the source location, and reassembling therecords at the target location in the same sequence as they appeared inthe originating source.

Offline Integration

Offline integration can be used to support offline operations of SEEsupported devices and components. These devices are not limited to POSregister and store mobile devices. Once the appropriate SEE componentsare configured and deployed on the devices or the store, under thecontrol of the Device Manager (the component that controls interactionwith a device and allows for a level of abstraction from the businesslogic) in the Foundation layer, each planned offline operation period ispreceded with a Pre-Offline integration operation which includesinstallation of updates to components if available and downloading ofany relevant supporting data like item and price for an ASDA PopupStore. At the completion of an offline operation period, a Post-Offlineintegration operation uploads any accumulated data from the offlineoperation onto the Store and Enterprise SEE systems which in turnupdates any relevant systems external to SEE. The Pre and Post Offlineintegration operations are based on synchronization of the SEEcomponents between the offline device and the Store/Enterprise systemsthrough the Orchestration and Federated Messaging layers.

An offline device equipped with components from the Federated Messaginglayer can retain information as messages to be sent when the offlinedevice is connected back to the Store/Enterprise systems in thePost-Offline integration operation. Otherwise any information that needsto be passed back to the Store/Enterprise systems is retained in someform of storage like files or database. Also any required pre-loadedinformation such as a relevant subset of item and price information isstored locally. This capability is also referred to herein asstore-and-forward.

In an example embodiment, a local information data service is providedso that components deployed for offline operations can be retainedwithin a retention period. The local information data service with aninternal data retention design pattern also addresses and optimizesresponse time and data latency requirements for online operations.Required data that is available in the local information data serviceand is within the data latency requirement can be retained and retrievedwithout going to a remote system of record in the Enterprise layer. Thelocal information data service also determines when and what to storewithin defined data retention policy while updating the remote externalsystem of record transparent to the requesting service. This local datarepository in the information data service is also where pre-loaded datafor offline operation can be saved.

In some embodiments, in support of unplanned offline operations, thereis Pre-Offline Integration operation scheduled periodically to run at afrequency depending on the availability requirements to prepare thedevices or store before any unplanned disruption occurs. This processfor example can allow devices in a store to continue sales operationwhen connections to the store or enterprise systems are disruptedunexpectedly.

Pre-Offline Integration

Before store based offline devices go into offline operation, they needto be prepared by downloading relevant and up-to-date data, such as itemand price information, from the store, enterprise and/or externalthird-party vendors. The data flow between the various environments maybe as described here. Data from the Enterprise Systems and Services inthe Enterprise Environment is downloaded through the Federated Messaginglayer into the subset of Enterprise Systems and Services deployed in theStore Environment. If necessary any required data from the third-partyvendors in the External Environment is downloaded into the Enterprise,Market and Foundation components in the Store Environment. Data isdownloaded through the Federated Messaging layer from the Foundationcomponents in the Store Environment into the subset of Foundationcomponents deployed in the Devices. Data is downloaded through theFederated Messaging layer from the Market components in the StoreEnvironment into the subset of Market components deployed in theDevices. Data is downloaded through the Federated Messaging layer fromthe Enterprise components in the Store Environment into the subset ofEnterprise components deployed in the Devices.

Post-Offline Data Integration

Once offline devices finish their operation, they upload relevant data,such as sales transactions, stored in their local data services ormessaging layer in the Devices back to the store, enterprise and/orexternal third-party vendors. The upload data may flow between thevarious environments as described here. Data is uploaded through theFederated Messaging layer from the Foundation components in the Devicesinto the Foundation components in the Store Environment. Data isuploaded through the Federated Messaging layer from the Marketcomponents in the Devices into the Market components in the StoreEnvironment. Data is uploaded through the Federated Messaging layer fromthe Enterprise components in the Devices into the Enterprise componentsin the Store Environment. If necessary any required data from theFoundation, Marketing or Enterprise components in the Store Environmentis uploaded into the third-party vendors in the External Environment.Data is uploaded through the Federated Messaging layer from theEnterprise components in the Store Environment into the Enterprisecomponents in the Enterprise Environment.

Services adopting the Internal Data Retention Design Patterns, discussedabove, may facilitate their offline deployment and integrations,contribute to high availability by being able to function with somefunctionality reduction under unplanned connectivity disruption, andenable support for optimum response time and data latency requirements.

FIG. 15 is a flowchart of an exemplary method 1500 for facilitatingexecution of a multi-step task using the SEP of the SEE, according to anexample embodiment. Method 1500 starts with operation 1502 receiving arequest to perform a task. The task is a commerce-related task in acommerce environment. The request may include context informationrelated to the task, where context information is information requiredto perform the task, such as the task to be performed and any inputs andoutput required for the task. For example, the context information mayinclude a customer name, an employee name, an item name, product serialnumber, and the like. This request may be sent by a device that iscapable of interacting with the SEP. The device may be received by thepresentation layer discussed above.

At operation 1504, a task flow, including sub-tasks is retrieved. Thetask flow may be referred to as an orchestration or a process. Thesub-tasks may be referred to as services, candidate services,sub-orchestrations, orchestrations, sub-processes, and processes. Theorchestration layer discussed may retrieve the task flow. The task flowmay be retrieved based on information provided in the request. In someembodiments, the request names the task flow to be retrieved. A numberof different task flows may be stored in a database, along with thesub-tasks included in the task flow. As discussed above, the processesin the SEP are made of various components to promote modularity of thesystem. The sub-tasks may form the various components that make up theprocess.

At operation 1506, components for sub-tasks are invoked, including rulesand events. As discussed above, there may be rules and events associatedwith a task flow and/or sub-tasks. These rules and events are associatedare saved as part of the task-flow and invoked as appropriate. In someembodiments, the rules and events are invoked based on a sequence inwhich the sub-tasks are executed. The rules may be evaluated by a rulesengine that is part of the orchestration layer. The events may betriggered and executed by an event manager that is part of thefoundation layer discussed above. A sub-task may have a task-flowassociated with itself that dictates the tasks, rules, and events to beinvoked to complete the sub-task. As an example, refer to exemplaryprocess 1000 shown in and discussed in connection with FIG. 10 .

At operation 1508, modifications to the sub-tasks are maintained. Anauthorized user may make modifications to a sub-task. Thesemodifications may reflect, for example, changes in technology or changesin the market. The user may also modify rules and events associated witha task-flow. A user may also configure a new task flow that containssub-tasks, rules, and events. The next time a task flow is invoked, themodified sub-tasks, rules and events are executed.

At operation 1510, a confirmation is sent that the task is completed.The confirmation is sent to the requesting component. In someembodiments, the orchestration layer sends a confirmation to thepresentation layer. After the confirmation is received, the presentationlayer may render a result of the task on the device that requested thetask.

FIG. 16 is a block diagram of an exemplary computing device 1600 thatmay be used to implement exemplary embodiments of the SEE describedherein or portions thereof. The computing device 1600 includes one ormore non-transitory computer-readable media for storing one or morecomputer-executable instructions or software for implementing exemplaryembodiments. The non-transitory computer-readable media may include, butare not limited to, one or more types of hardware memory, non-transitorytangible media (for example, one or more magnetic storage disks, one ormore optical disks, one or more flash drives), and the like. Forexample, memory 1606 included in the computing device 1600 may storecomputer-readable and computer-executable instructions or software forimplementing exemplary embodiments of the SEE 1636. One or morecomputational components illustrated in FIG. 9 can be included in theSEE 1636. In some embodiments, SEE 1636 includes the “Add Items toBasket” component 901, the “Personalized Coupons” component 902, the“Total Order” component 903, the “Collect Payment” component 904, andthe “Record the Sale” component 905. However, depending on thetransaction, one or more components may not be invoked or called toexecute the sales transaction.

The computing device 1600 also includes configurable and/or programmableprocessor 1602 and associated core 1604, and optionally, one or moreadditional configurable and/or programmable processor(s) 1602′ andassociated core(s) 1604′ (for example, in the case of computer systemshaving multiple processors/cores), for executing computer-readable andcomputer-executable instructions or software stored in the memory 1606and other programs for controlling system hardware. Processor 1602 andprocessor(s) 1602′ may each be a single core processor or multiple core(1604 and 1604′) processor.

Virtualization may be employed in the computing device 1600 so thatinfrastructure and resources in the computing device may be shareddynamically. A virtual machine 1614 may be provided to handle a processrunning on multiple processors so that the process appears to be usingonly one computing resource rather than multiple computing resources.Multiple virtual machines may also be used with one processor.

Memory 1606 may include a computer system memory or random accessmemory, such as DRAM, SRAM, EDO RAM, and the like. Memory 1606 mayinclude other types of memory as well, or combinations thereof.

A user may interact with the computing device 1600 through a visualdisplay device 1618, such as a computer monitor, which may display oneor more graphical user interfaces that may be provided in accordancewith exemplary embodiments. The computing device 1600 may include otherI/O devices for receiving input from a user, for example, a keyboard orany suitable multi-point touch interface 1608, a pointing device 1610(e.g., a mouse), a microphone 1628, and/or an image capturing device1632 (e.g., a camera or scanner). The multi-point touch interface 1608and the pointing device 1610 may be coupled to the visual display device1618. The computing device 1600 may include other suitable conventionalI/O peripherals.

The computing device 1600 may also include one or more storage devices1624, such as a hard-drive, CD-ROM, or other computer readable media,for storing data and computer-readable instructions and/or software thatimplement exemplary embodiments of the SEE 1636 described herein.Exemplary storage device 1624 may also store one or more databases forstoring any suitable information required to implement exemplaryembodiments. For example, exemplary storage device 1624 can store one ormore databases 1626 for storing information, such as productinformation, customer information, market information, orchestrationinformation, actors, devices, security protocols, rules, events,services, tasks, store information, and/or any other information to beused by embodiments of the SEE 1636. The databases may be updatedmanually or automatically at any suitable time to add, delete, and/orupdate one or more items in the databases.

The computing device 1600 can include a network interface 1612configured to interface via one or more network devices 1620 with one ormore networks, for example, Local Area Network (LAN), Wide Area Network(WAN) or the Internet through a variety of connections including, butnot limited to, standard telephone lines, LAN or WAN links (for example,802.11, T1, T3, 56 kb, X.25), broadband connections (for example, ISDN,Frame Relay, ATM), wireless connections, controller area network (CAN),or some combination of any or all of the above. In exemplaryembodiments, the computing device 1600 can include one or more antennas1630 to facilitate wireless communication (e.g., via the networkinterface) between the computing device 1600 and a network. The networkinterface 1612 may include a built-in network adapter, network interfacecard, PCMCIA network card, card bus network adapter, wireless networkadapter, USB network adapter, modem or any other device suitable forinterfacing the computing device 1600 to any type of network capable ofcommunication and performing the operations described herein. Moreover,the computing device 1600 may be any computer system, such as aworkstation, desktop computer, server, laptop, handheld computer, tabletcomputer (e.g., the iPad™ tablet computer), mobile computing orcommunication device (e.g., the iPhone™ communication device), point-ofsale terminal, internal corporate devices, or other form of computing ortelecommunications device that is capable of communication and that hassufficient processor power and memory capacity to perform the operationsdescribed herein.

The computing device 1600 may run any operating system 1616, such as anyof the versions of the Microsoft® Windows® operating systems, thedifferent releases of the Unix and Linux operating systems, any versionof the MacOS® for Macintosh computers, any embedded operating system,any real-time operating system, any open source operating system, anyproprietary operating system, or any other operating system capable ofrunning on the computing device and performing the operations describedherein. In exemplary embodiments, the operating system 1616 may be runin native mode or emulated mode. In an exemplary embodiment, theoperating system 1616 may be run on one or more cloud machine instances.

FIG. 17 is a block diagram of an exemplary client-server environment1700 configured to implement one or more embodiments of the environment100. The environment 1700 includes servers 1710-1713 operatively coupledto clients 1720-1722, via a communication network 1750, which can be anynetwork over which information can be transmitted between devicescommunicatively coupled to the network. For example, the communicationnetwork 1750 can be the Internet, an Intranet, virtual private network(VPN), wide area network (WAN), local area network (LAN), and the like.The environment 1700 can include repositories or databases 1730-1734,which can be operatively coupled to the servers 1710-1713, as well as toclients 1720-1722, via the communications network 1750. The servers1710-1713, clients 1720-1722, and databases 1730-1734 can be implementedas computing devices. Those skilled in the art shall recognize that thedatabase devices 1730-1734 can be incorporated into one or more of theservers 1710-1713 such that one or more of the servers can includedatabases. In an exemplary embodiment, different portions of the SEE1636 can be implemented by one or more of the server 1711-1713 and/ordatabases 1730-1734.

The client devices 1720-1722 can include a client side application 1723programmed and/or configured to access or execute the system tofacilitate a sales transaction as described herein. In the presentembodiment, the client devices 1720-1722 can be computing devicesincluding, for example, portable computing devices. In one embodiment,the client-side application 1723 implemented by the client device 1720can be a web-browser capable of navigating to one or more web pageshosting GUIs of the SEE and the client-side application 1723 implementedby the client device 1721 can be a GUI of the SEE. For example, in someembodiments, the client-side application 1723 implemented by one or moreof the client devices 1720-1722 (e.g., portable computing devices) canbe an application specific to the SEE and the SEP, which is installed onthe client devices 1720-1722 to permit access to a GUI(s) of the SEE orthe application can be portions of the SEE itself. In some embodiments,the application specific to the SEE can be a mobile applicationinstalled and executed by a portable computing device. In exemplaryembodiments, the client devices 1720-1722 can be configured tocommunicate with the network 1750 via wired and/or wirelesscommunication.

The databases 1730-1734 can store information for use by the SEE andSEP. For example, the database 1730 can store information related toactors and devices capable of interacting with the SEP, the database1731 can store information for Market and Enterprise interfaces andinformation communicated between the interfaces and the SEP, thedatabase 1732 can store information related to the store systems withinthe SEP, the database 1733 can store information related to thearchitectural layers of the SEP, and the database 1734 can storeinformation related to candidate services and components of the SEP.

In describing exemplary embodiments, specific terminology is used forthe sake of clarity. For purposes of description, each specific term isintended to at least include all technical and functional equivalentsthat operate in a similar manner to accomplish a similar purpose.Additionally, in some instances where a particular exemplary embodimentincludes a plurality of system elements, device components or methodsteps, those elements, components or steps may be replaced with a singleelement, component or step. Likewise, a single element, component orstep may be replaced with a plurality of elements, components or stepsthat serve the same purpose. Moreover, while exemplary embodiments havebeen shown and described with references to particular embodimentsthereof, those of ordinary skill in the art shall understand thatvarious substitutions and alterations in form and detail may be madetherein without departing from the scope of the invention. Furtherstill, other embodiments, functions and advantages are also within thescope of the invention.

Exemplary flowcharts are provided herein for illustrative purposes andare non-limiting examples of methods. One of ordinary skill in the artshall recognize that exemplary methods may include more or fewer stepsthan those illustrated in the exemplary flowcharts, and that the stepsin the exemplary flowcharts may be performed in a different order thanthe order shown in the illustrative flowcharts.

1-20. (canceled)
 21. A computer-implemented method of executing amultistep commerce-related task in a commerce environment, the methodcomprising: receiving a request in a computer-readable format forexecution of a commerce-related task in a commerce environment;programmatically retrieving a task flow from a non-transitorycomputer-readable medium in response to the request, the task flowidentifying a plurality of sub-tasks and defining a sequence with whichto execute the plurality of sub-tasks to facilitate completion of thecommerce-related task; and controlling an order of execution of theplurality of sub-tasks according to the sequence defined by the taskflow, the plurality of sub-tasks being executed independently anddiscretely of each other.
 22. The method of claim 21, furthercomprising: receiving a request to evaluate a rule associated with oneof the plurality of sub-tasks; and evaluating the rule based on criteriacorresponding to the rule.
 23. The method of claim 21, furthercomprising: receiving a request to execute a sub-task of the pluralityof sub-tasks; invoking a service corresponding to the sub-task, theservice facilitating execution of the sub-task; receiving a result ofthe sub-task as a result of execution of the sub-task; and sendingconfirmation that the sub-task is executed.
 24. The method of claim 21,wherein the request is received from a client device.
 25. The method ofclaim 24, wherein the client device comprises a device used by at leastone of a customer, a sales associate, a department manager, a floormanager, a sales manager, an inventory manager, a supplier, adistributor, and a third-party vendor.
 26. The method of claim 21,wherein the commerce-related task comprises at least one of adding anitem to a shopping cart, ordering an item, checking a price of an item,calculating a shipping cost for an item, paying for an item, andreturning an item.
 27. The method of claim 21, wherein the requestincludes context information associated with the commerce-related task,the context information required to execute the plurality of sub-tasksof the task flow.
 28. The method of claim 21, further comprisingreceiving a modification of the sub-task, and implementing themodification of the sub-task.
 29. A system for executing a multistepcommerce-related task in a commerce environment, the system comprising:a processor implemented orchestration module configured to: receive arequest in a computer-readable format for execution of acommerce-related task in a commerce environment; retrieve a task flowfrom a non-transitory computer-readable medium in response to therequest, the task flow identifying a plurality of sub-tasks and defininga sequence with which to execute the plurality of sub-tasks tofacilitate completion of the commerce-related task; and control an orderof execution of the plurality of sub-tasks according to the sequencedefined by the task flow, the plurality of sub-tasks being executedindependently and discretely of each other.
 30. The system of claim 29,further comprising a rule module configured to: receive a request toevaluate a rule associated with one of the plurality of sub-tasks; andevaluate the rule based on criteria corresponding to the rule.
 31. Thesystem of claim 29, wherein the orchestration module is furtherconfigured to: receive a request to execute a sub-task of the pluralityof sub-tasks; invoke a service corresponding to the sub-task, theservice facilitating execution of the sub-task; receive a result of thesub-task as a result of execution of the sub-task; and send confirmationthat the sub-task is executed.
 32. The system of claim 29, furthercomprising an extension module configured to: receive a modification ofthe sub-task; and implement the modification of the sub-task.
 33. Thesystem of claim 29, wherein the request includes context informationassociated with the commerce-related task, the context informationrequired to execute the plurality of steps of the task flow.
 34. Thesystem of claim 29, wherein the commerce-related task comprises at leastone of adding an item to a shopping cart, ordering an item, checking aprice of an item, calculating a shipping cost for an item, paying for anitem, and returning an item.
 35. The system of claim 29, wherein therequest is received from a client device.
 36. A non-transitorycomputer-readable storage device configured to store instructionsexecutable by a processing device, wherein execution of the instructionsin a commerce environment causes the processing device to implement amethod of executing a multistep commerce-related task in the commerceenvironment comprising: receiving a request in a computer-readableformat for execution of a commerce-related task in a commerceenvironment; retrieving a task flow in response to the request, the taskflow identifying a plurality of sub-tasks and defining a sequence withwhich to execute the plurality of sub-tasks to facilitate completion ofthe commerce-related task; and controlling an order of execution of theplurality of sub-tasks according to the sequence defined by the taskflow, the plurality of sub-tasks being executed independently anddiscretely of each other.
 37. The non-transitory storage device of claim36, wherein the method implemented upon execution of the instructions bythe processing device further comprises: receiving a request to evaluatea rule associated with one of the plurality of sub-tasks; and evaluatingthe rule based on criteria corresponding to the rule.
 38. Thenon-transitory storage device of claim 36, wherein the methodimplemented upon execution of the instructions by the processing devicefurther comprises: receiving a request to execute a sub-task of theplurality of sub-tasks; invoking a service corresponding to thesub-task, the service facilitating execution of the sub-task; receivinga result of the sub-task as a result of execution of the sub-task; andsending confirmation that the sub-task is executed.
 39. Thenon-transitory storage device of claim 36, wherein the commerce-relatedtask comprises at least one of adding an item to a shopping cart,ordering an item, checking a price of an item, calculating a shippingcost for an item, paying for an item, and returning an item.
 40. Thenon-transitory storage device of claim 36, wherein the request includescontext information associated with the commerce-related task, thecontext information required to execute the plurality of sub-tasks ofthe task flow. 41-80. (canceled)